Re: W32 version crashes on C-g

[Chong Yidong <cyd@stupidchicken.com>]

Jason Rumney <jasonr@gnu.org> writes:

> from nt/INSTALL:
>
>   MSYS sh.exe also appears to cause various problems. If you have
>   MSYS installed, try "make SHELL=cmd.exe" to force the use of cmd.exe
>   instead of sh.exe.
>
> Emacs used to build only with msvc, nmake and cmd.exe. The problem
> with this situation is that it is a non-Free set of tools. A lot of
> effort was put in to make Emacs build with gcc. Bug reports quickly
> came in that Emacs didn't build with Cygwin bash as the shell, so this
> was fixed. Now we have people complaining that it doesn't build with
> MSYS as the shell, despite the INSTALL file warning against that.

That's the nature of progress.

This is somewhat off-topic, but a long time ago, I posted on
gnu.emacs.help that a small tweak to a Makefile allows Emacs to
compile with the version of make that comes with MingW/MSYS, even in
the MSYS shell:

  I get an error when compiling Emacs 21.3 on Windows 2000, using
  Mingw's gcc.exe and mingw32-make.exe (renamed to make.exe):

  "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte
  -l autoload \
          --eval "(setq find-file-hook nil \
                  find-file-suppress-same-file-warnings t \
                  generated-autoload-file \
                    \"C:/home/emacs/lisp/loaddefs.el\")" \
          -f batch-update-autoloads "C:/home/emacs/lisp"
  Wrote c:/home/emacs/lisp/C;c:home.macslisploaddefs.el
  Loading vc-cvs (source)...
  Wrote c:/home/emacs/lisp/C;c:home?macslisploaddefs.el
  Autoloads file c:/home/emacs/lisp/C;c:home.macslisploaddefs.el does
  not exist
  make: *** [all] Error -1

  The problem seems to be that either emacs.exe or cmd (the Windows
  command shell) munges the ":" character, even when it is enclosed by
  quotation marks. If I edit the Makefile by hand to eliminate the
  colon, i.e.,

                    \"./loaddefs.el\")" \

  then the compilation succeeds.

> It is clear that people will use whatever tools and shells they want
> to, and we must do our best to make them work and document it. While
> singling out one toolset to document might make things easier for
> newcomers, it will also offend a large number of zealots who prefer
> some other toolset.

We can probably live with a bit of offense.