Re: W32 version crashes on C-g

[Eli Zaretskii]

> Cc: Eli Zaretskii <address@hidden>,  "Kim F. Storm" <address@hidden>,
>         address@hidden
> From: Chong Yidong <address@hidden>
> Date: Sat, 18 Mar 2006 14:11:48 -0500
> 
> 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.

This complaint came in a few more times from other users of MSYS.
Further enquiry uncovered the reason: the MSYS runtime would munge
strings which start with "C:" (or "D:" or "E:" etc.) if these were not
the first two characters of a string.  That is, "C:/foo something"
would be left alone, but "(setq foo \"C:/foo\")" would be munged.

You will see that in current CVS, lisp/makefile.w32-in avoids
triggering this MSYS bug, albeit in a way that is different from what
you suggested (because what you suggested would break a build outside
the source tree).

So obviously, once the problems are understood, we do try to solve
them, even if they are due to what I firmly believe to be an MSYS
misfeature.

> > 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.

I don't think a request to have simpler instructions is a good reason
to stop catering to a significant portion of users.