emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loaddefs.el on Windows incomplete


From: Eli Zaretskii
Subject: Re: loaddefs.el on Windows incomplete
Date: Sun, 18 Dec 2005 21:11:53 +0200

> From: Ralf Angeli <address@hidden>
> Date: Sun, 18 Dec 2005 16:56:18 +0100
> 
> > 2005-07-08  Ralf Angeli  <address@hidden>
> >
> >     * makefile.w32-in (autoloads): Do not let autoload file name be
> >     mangled by the shell.
> 
> I'd like to followup on this because until now nothing has happened
> and I've been bitten by this problem again, namely the build process
> failed to update the autoloads but instead of aborting with an error,
> it completed "successfully".  This happens with MSYS' `make' and `sh'.
> 
> The patch mentioned above allowed me to build successfully, i.e. with
> updated autoloads, with `mingw32-make' and MSYS' `sh'.  After the
> inclusion of MH-E a similar statement like the one for building the
> autoloads for Emacs in general is used for MH-E as well.  That means
> the patch mentioned above does not work anymore.  Below you can find
> an updated version.
> 
> I'd very much appreciate it if this patch were applied or the build
> process be aborted if the autoloads cannot be updated.

Thanks for following up on this.

However, I cannot accept your patch as it stands.  First, you missed
the important WARNING in the comment just preceding the commands you
wanted to patch, and thus your modified command lines will break with
make 3.81 (which is about to be released) and later, due to the
incompatible change in its behavior regarding backslash-newline
sequences.

More to the point, I've just re-read the thread back from July that
started here:

  http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00082.html

and the MSYS discussion related to it that starts here:

  http://thread.gmane.org/gmane.comp.gnu.mingw.msys/2715

and it seems to me that you are looking at a bug or misfeature in
either MSYS runtime or its port of Bash: they shouldn't second-guess
what the user means when she passes a quoted string to a subsidiary
program, and shouldn't modify that string in any way except remove one
level of quotes and escape characters.

So I'm inclined to tell users not to use this MSYS port of Bash for
building Emacs.  That is because the build system for the MS-Windows
port of Emacs needs to support a variety of OS versions, development
environments, and combinations of shells and Make, and it is therefore
already very fragile.  Making significant modifications to it, such as
those you proposed, especially so late in the development of Emacs
22.0, would run a high risk of breaking some supported combination,
unless either (1) someone volunteers to test the modification on all
supported systems and with all supported combinations of development
tool--a formidable job for which I don't expect volunteers to line
up--or (2) the change is entirely orthogonal to the other
combinations, which means you will have to modify configure.bat to
detect MSYS, and then modify nt/gmake.defs and the makefile.w32-in
files to set variables such as ARGQUOTE and the file-name variables
that use $(CURDIR), as appropriate for the MSYS shell.  I think both
these alternatives are quite impractical.

Is there any reasonable chance that MSYS maintainers will fix this?
Could you check with them, or maybe try their latest snapshot of
ported Bash and see if the problem went away?

If they don't intend to fix that any time soon, we will need to find a
much simpler solution, one for which we could know with high
probability that it will not break anything else.  I'll give it a
thought while you talk to the MSYS people.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]