* Eli Zaretskii (2005-07-09) writes: >> From: Ralf Angeli <[EMAIL PROTECTED]> >> >> + --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 _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
