[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: W32 version crashes on C-g
From: |
Chong Yidong |
Subject: |
Re: W32 version crashes on C-g |
Date: |
Sat, 18 Mar 2006 14:11:48 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Jason Rumney <address@hidden> 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.
- 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 <=
- Re: W32 version crashes on C-g, Eli Zaretskii, 2006/03/18
- 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