[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: W32 version crashes on C-g
From: |
Eli Zaretskii |
Subject: |
Re: W32 version crashes on C-g |
Date: |
Sun, 19 Mar 2006 00:38:57 +0200 |
> 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.
- Re: W32 version crashes on C-g, (continued)
- RE: W32 version crashes on C-g, Drew Adams, 2006/03/20
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
- Re: W32 version crashes on C-g, Kim F. Storm, 2006/03/18
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
- Re: W32 version crashes on C-g, Eric Hanchrow, 2006/03/18
- Re: W32 version crashes on C-g, Chong Yidong, 2006/03/18
- Re: W32 version crashes on C-g, Jason Rumney, 2006/03/18
- Re: W32 version crashes on C-g, Chong Yidong, 2006/03/18
- Re: W32 version crashes on C-g,
Eli Zaretskii <=
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/20
- Re: W32 version crashes on C-g, Kim F. Storm, 2006/03/18
- Re: W32 version crashes on C-g, Eric Hanchrow, 2006/03/18
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
- Re: W32 version crashes on C-g, Jason Rumney, 2006/03/18
- Re: W32 version crashes on C-g, Eric Hanchrow, 2006/03/18
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
Re: W32 version crashes on C-g, LENNART BORGMAN, 2006/03/20