Re: loaddefs.el on Windows incomplete

[Ralf Angeli]

* Eli Zaretskii (2005-07-09) writes:

>> From: Ralf Angeli <address@hidden>
>> 
>> +               --eval $(ARGQUOTE)(let ((find-file-hook nil) \
>> +                       (find-file-suppress-same-file-warnings t) \
>> +                       (generated-autoload-file \
>> +                         (expand-file-name (pop command-line-args-left)))) \
>> +                       (mapcar (function update-directory-autoloads) \
>> +                         command-line-args-left) \
>> +                       (save-buffers-kill-emacs t))$(ARGQUOTE) \
>> +               "$(lisp)/loaddefs.el" $(lisp) $(WINS)
>
> Good God!  Can you please explain why we need such a monstrosity with
> MSYS, and why the original version fails (i.e., why is the file name
> mangled)?

I don't know exactly.  I suspect that the MSYS shell regards the colon
as a path separator and tries to replace it by a semi-colon and a path
prefix.  In order to find out I asked on the MSYS mailing list about
it but haven't got an answer about this specific issue yet.  You can
find the thread at
<URL:http://thread.gmane.org/gmane.comp.gnu.mingw.msys/2715>.

> It's hard to argue about this patch without understanding
> that much, and it's harder still to try to figure out whether it might
> hamper other build environments.  (FWIW, my environment is identical
> to yours except that the shell is not the one from MSYS.  I have no
> problems with the original command, although I use the same port of
> Make.)

The patch simply makes sure that the path will not get altered by the
shell.  Like this it doesn't matter if the behavior of the MSYS shell
is correct or not.  Otherwise, if you wanted to build Emacs with both
MinGW and MSYS installed, you would have to rename sh.exe before
calling mingw32-make which will then fall back to comspec.  With the
patch it doesn't matter, so the build process should be more robust.

> Btw, isn't MinGW 4.1.0 a development snapshot, not a released version?
> If so, perhaps it's a bug in that version of MinGW (I have 3.7 on my
> box).

On MinGW's download page 4.1.0 is listed under "Current".

-- 
Ralf