Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-24) writes: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? Okay, now I tried again and creation of autoloads works. I checked this with MinGW's mingw32-make and MSYS' make. In both cases lisp/autoloads.el is created with only a small difference: $ diff -u build-with-mingw32-make/lisp/loaddefs.el build-with-make/lisp/loaddefs.el --- build-with-mingw32-make/lisp/loaddefs.el Wed Dec 28 20:40:22 2005 +++ build-with-make/lisp/loaddefs.el Wed Dec 28 21:29:32 2005 @@ -29910,7 +29910,7 @@ ;; url/url-vars.el url/vc-dav.el vc-hooks.el vcursor.el ;; version.el vms-patch.el vmsproc.el vt-control.el ;; vt100-led.el w32-fns.el w32-vars.el widget.el window.el -;; x-dnd.el) (17330 63506 99000)) +;; x-dnd.el) (17331 923 346000)) ;;;*** I don't know if this is significant, though. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
From: Ralf Angeli [EMAIL PROTECTED] Date: Wed, 28 Dec 2005 23:22:40 +0100 Okay, now I tried again and creation of autoloads works. I checked this with MinGW's mingw32-make and MSYS' make. In both cases lisp/autoloads.el is created with only a small difference: $ diff -u build-with-mingw32-make/lisp/loaddefs.el build-with-make/lisp/loaddefs.el --- build-with-mingw32-make/lisp/loaddefs.el Wed Dec 28 20:40:22 2005 +++ build-with-make/lisp/loaddefs.el Wed Dec 28 21:29:32 2005 @@ -29910,7 +29910,7 @@ ;; url/url-vars.el url/vc-dav.el vc-hooks.el vcursor.el ;; version.el vms-patch.el vmsproc.el vt-control.el ;; vt100-led.el w32-fns.el w32-vars.el widget.el window.el -;; x-dnd.el) (17330 63506 99000)) +;; x-dnd.el) (17331 923 346000)) ;;;*** I don't know if this is significant, though. It isn't: that's the time when loaddefs.el was updated. Thanks for testing; I can now consider this issue resolved. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-24) writes: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? Thanks for your efforts. I did a fresh checkout into a new directory, ran `configure ...' and while doing `mingw32-make bootstrap' the following error occurred: --8---cut here---start-8--- ./../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)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- In order to get a backtrace I set `debug-on-error' to t via the --eval statement above. That means I edited lisp/makefile.w32-in accordingly and ran `configure' again. Interestingly the error did not occur with this change. I tried this both in the directory where the make call failed with the original makefile.w32-in and in a directory which had not seen a make call before. Same results. Then I tried to run `mingw32-make bootstrap' in a freshly checked out and configured directory including the patch I proposed for lisp/makefile.w32-in and got the same error as above. Let-binding `debug-on-error' to t made the error vanish again. Now I don't really know where to look for the cause of the error. Anyway, in the directories where the build succeeded I did a `diff -u loaddefs.el ldefs-boot.el' which showed no differences between the files. The build I did about a week ago (with the patch I proposed) shows lots of differences between the files. So I am not really sure if loaddefs.el was generated correctly. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
Cc: emacs-pretest-bug@gnu.org From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 26 Dec 2005 16:56:17 +0100 Thanks for your efforts. I did a fresh checkout into a new directory, ran `configure ...' and while doing `mingw32-make bootstrap' the following error occurred: --8---cut here---start-8--- ./../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)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- A weird error. In order to get a backtrace I set `debug-on-error' to t via the --eval statement above. That means I edited lisp/makefile.w32-in accordingly and ran `configure' again. Interestingly the error did not occur with this change. I tried this both in the directory where the make call failed with the original makefile.w32-in and in a directory which had not seen a make call before. Same results. Still weirder. But see below. Then I tried to run `mingw32-make bootstrap' in a freshly checked out and configured directory including the patch I proposed for lisp/makefile.w32-in and got the same error as above. So the problem doesn't seem to be due to the changes, but to something else. Did you remember to check out the Emacs tree with the -kb switch to the co command? If not, perhaps what you see is due to some EOL-related snafu. Let-binding `debug-on-error' to t made the error vanish again. Now I don't really know where to look for the cause of the error. How about editing lisp/makefile so that Emacs displays its command-line arguments (via `message') before doing anything else? Something like this: ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(message %s command-line-args)' --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url What does it print, if you try this? If this makes the problem go away, please pay attention to the EOL format of the files that get concatenated into makefile: gmake.defs, the preamble produced by configure.bat, and makefile.w32-in. Anyway, in the directories where the build succeeded I did a `diff -u loaddefs.el ldefs-boot.el' which showed no differences between the files. That's because loaddefs.el never go created, due to the error. Since bootstrap first copies ldefs-boot.el into loaddefs.el, it is expected that they both be identical if the real loaddefs.el fails to be created. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
Cc: emacs-pretest-bug@gnu.org From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 26 Dec 2005 16:56:17 +0100 ./../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)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 See the thread Re: Can't create loaddefs.el --- this is a new problem, unrelated to the changes I made. Just wait for a while, until this new problem is solved, and then re-sync and try again. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
From: Ralf Angeli [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Mon, 19 Dec 2005 12:23:37 +0100 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? I reported the issue back in July, see URL:http://thread.gmane.org/[EMAIL PROTECTED]. So they are aware of it but I don't know if this is fixed yet. I've been waiting for ages for a new release of MSYS. IIRC I checked a beta version of Bash 2.05 for MSYS back in July which did not solve the problem. Unfortunately I cannot find that beta on their download page anymore for testing. And the last beta of MSYS itself is from April 2004. 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. Well, I am. (c: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-18) writes: 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, Oh great, then I'll probably have to do another upload to alpha.gnu.org. At least because of the usage of $(lisp). But I'll have to check how bad the consequences of missing autoloads are when relocating the Emacs installation directory. Thanks for the hint. 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. You mean the changes you described in the patch to make.texi in URL:http://lists.gnu.org/archive/html/help-make/2005-12/msg00031.html? In what way is this a problem. For example it does not make a difference if I pass emacs -eval (message \ \foo\) or emacs -eval (message \foo\) to the Bash 3.1.0 on my Debian system directly from a terminal. Is this relevant for Windows systems only? Does it mean that portable Makefile files all have to put their `emacs -eval ...' stuff into a single line? I am not sure about the conditions because the comment in lisp/makefile.w32-in mentions $(ARGQUOTE) and the patch in the email references above is mangled and reads [...]However, note that +backslash-newline sequences inside command-line arguments quoted with [EMAIL PROTECTED]'...'} are not removed by the shell.[...] 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? I reported the issue back in July, see URL:http://thread.gmane.org/[EMAIL PROTECTED]. So they are aware of it but I don't know if this is fixed yet. I've been waiting for ages for a new release of MSYS. IIRC I checked a beta version of Bash 2.05 for MSYS back in July which did not solve the problem. Unfortunately I cannot find that beta on their download page anymore for testing. And the last beta of MSYS itself is from April 2004. 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. Well, I am. (c: -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
From: Ralf Angeli [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Date: Mon, 19 Dec 2005 12:23:37 +0100
* Eli Zaretskii (2005-12-18) writes:
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,
Oh great, then I'll probably have to do another upload to
alpha.gnu.org.
Sorry, I'm confused: what upload to alpha.gnu? What did you upload
there, and how is this discussion relevant to whatever you uploaded?
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.
You mean the changes you described in the patch to make.texi in
URL:http://lists.gnu.org/archive/html/help-make/2005-12/msg00031.html?
Yes.
In what way is this a problem. For example it does not make a
difference if I pass
emacs -eval (message \
\foo\)
or
emacs -eval (message \foo\)
to the Bash 3.1.0 on my Debian system directly from a terminal.
Inside double quotes, it indeed will not make any difference, because
the shell removes the backslashes inside double quotes. But in single
quotes, the shell will not remove the backslashes, so they will wind
up inside the Emacs Lisp reader, and will utterly confuse it. Note
that, when the shell is sh.exe, lisp/makefile.w32-in uses single
quotes to quote the --eval argument in the command you wanted to
patch.
Is this relevant for Windows systems only?
No, it is relevant to GNU Make on any platform which uses a Posix
shell (and thus on Windows when the shell is sh.exe).
However, in this specific case it is relevant only to Windows, since
makefile.w32-in is used only by the MS-Windows build.
Does it mean that portable Makefile files all have to put their
`emacs -eval ...' stuff into a single line?
Not just `emacs --eval ...' stuff, but _any_ command parts that are
quoted with single quotes cannot be split across multiple lines with
backslash-newline sequences.
I am not sure about the conditions because the comment
in lisp/makefile.w32-in mentions $(ARGQUOTE)
$(ARGQUOTE) expands to different kinds of quotes depending on the
shell in use (see nt/nmake.defs and nt/gmake.defs); the problem
happens when it expands to ', a single quote. I didn't want to
mention a single quote literally because it does not appear in the
commands in question, so the reader might be left wandering what quote
I was talking about.
and the patch in the email references above is mangled and reads
[...]However, note that
+backslash-newline sequences inside command-line arguments quoted with
[EMAIL PROTECTED]'...'} are not removed by the shell.[...]
Talk about stupid software! The original patch I sent says this:
+sequences, per shell quoting rules. However, note that
+backslash-newline sequences inside command-line arguments quoted with
[EMAIL PROTECTED]'...'} are not removed by the shell. Also, the MS-DOS and
+MS-Windows ports of @code{make} @strong{do} remove backslash-newline
+sequences when the shell to be used is not a Unix-style shell.
The mailing list software probably thought that @code is an email
address, and tried to conceal it.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-08) writes: * Ralf Angeli (2005-07-07) writes: Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: [...] Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 Okay, with the following patch (thanks, David, for reminding me of the technique) I can build Emacs under Windows using mingw32-make (MinGW 4.1.0) with MSYS' (1.0.10) sh.exe either present or not. 2005-07-08 Ralf Angeli [EMAIL PROTECTED] * 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. Index: makefile.w32-in === RCS file: /sources/emacs/emacs/lisp/makefile.w32-in,v retrieving revision 1.53 diff -u -r1.53 makefile.w32-in --- makefile.w32-in 17 Dec 2005 17:27:35 - 1.53 +++ makefile.w32-in 18 Dec 2005 15:47:21 - @@ -158,8 +158,14 @@ autoloads: $(lisp)/loaddefs.el doit @echo Directories: . $(WINS) $(emacs) -l autoload \ - --eval $(ARGQUOTE)(setq find-file-hook nil find-file-suppress-same-file-warnings t generated-autoload-file $(DQUOTE)$(lisp)/loaddefs.el$(DQUOTE))$(ARGQUOTE) \ - -f batch-update-autoloads . $(WINS) + --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) $(lisp)/subdirs.el: $(MAKE) $(MFLAGS) update-subdirs @@ -310,11 +316,16 @@ rm pre-mh-loaddefs.el-$(SHELLTYPE) $(EMACS) $(EMACSOPT) \ -l autoload \ - --eval (setq generate-autoload-cookie \;;;###mh-autoload\) \ - --eval (setq generated-autoload-file \$(lisp)/mh-e/mh-loaddefs.el\) \ - --eval (setq find-file-suppress-same-file-warnings t) \ - --eval (setq make-backup-files nil) \ - -f batch-update-autoloads $(lisp)/mh-e + --eval $(ARGQUOTE)(let ((find-file-hook nil) \ + (find-file-suppress-same-file-warnings t) \ + (make-backup-files nil) \ + (generate-autoload-cookie ;;;###mh-autoload) \ + (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)/mh-e/mh-loaddefs.el $(lisp)/mh-e pre-mh-loaddefs.el-SH: echo ;;; mh-loaddefs.el --- automatically extracted autoloads $@ -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
From: Ralf Angeli [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 16:56:18 +0100 2005-07-08 Ralf Angeli [EMAIL PROTECTED] * 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* 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 Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-07-09) writes: It's strange: MinGW-4.1.0.exe is under Current, but MinGW Runtime is still at version 3.7. What is inside MinGW-X.Y.Z.exe---isn't it the runtime plus the compiler and Binutils? I don't remember what was packaged with it. And as I am currently enjoying my GNU system I don't want to ruin my day by booting Windows. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-07) writes: Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: [...] Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 Okay, with the following patch (thanks, David, for reminding me of the technique) I can build Emacs under Windows using mingw32-make (MinGW 4.1.0) with MSYS' (1.0.10) sh.exe either present or not. 2005-07-08 Ralf Angeli [EMAIL PROTECTED] * makefile.w32-in (autoloads): Do not let autoload file name be mangled by the shell. --- makefile.w32-in 4 Jul 2005 23:08:56 - 1.44 +++ makefile.w32-in 8 Jul 2005 20:52:06 - @@ -149,11 +149,14 @@ autoloads: loaddefs.el doit @echo Directories: $(WINS) $(emacs) -l autoload \ - --eval $(ARGQUOTE)(setq find-file-hook nil \ - find-file-suppress-same-file-warnings t \ - generated-autoload-file \ - $(DQUOTE)$(lisp)/loaddefs.el$(DQUOTE))$(ARGQUOTE) \ - -f batch-update-autoloads $(lisp) $(WINS) + --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) subdirs.el: $(MAKE) $(MFLAGS) update-subdirs -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-06) writes: loaddefs.el in a Windows build checked out and compiled yesterday doesn't seem to include all autoloads. For example the autoloads for latexenc.el are missing. I suspect this is the cause for LaTeX files in a Windows build of Emacs being opened with a raw-text-dos coding system (which prevents character code conversion and therefore leads to other problems). Maybe I should add that these problems manifest themselves in duplicated ^M line endings every time a file is edited, saved and reopened if there are non-ASCII characters in the buffer. That means after doing this a few times one will end up with ^M^M^M^M^M^M. So Windows users editing (La)TeX files and using non-ASCII characters in these files should either take precautions not to end up with raw-text buffers or stay away from CVS Emacs until this is fixed. Another error which is likely caused by the incomplete loaddefs.el is that Makefile mode (makefile-gmake-mode in particular) cannot be activated when a Makefile is opened. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
Ralf Angeli wrote: * Ralf Angeli (2005-07-06) writes: loaddefs.el in a Windows build checked out and compiled yesterday doesn't seem to include all autoloads. For example the autoloads for latexenc.el are missing. I suspect this is the cause for LaTeX files in a Windows build of Emacs being opened with a raw-text-dos coding system (which prevents character code conversion and therefore leads to other problems). Can you please try to debug what has caused this on your machine. I do not have this problem, and noone else has reported it either. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Jason Rumney (2005-07-07) writes: Can you please try to debug what has caused this on your machine. I do not have this problem, and noone else has reported it either. Okay, I inserted a `sleep 60' at the end of the `autoloads' target of lisp/makefile and this is what I could observe during a `make bootstrap': --8---cut here---start-8--- make[1]: Entering directory `/d/software/windows/unix/src/emacs/lisp' /d/software/windows/unix/src/emacs/lisp/../update-subdirs /d/software/windows/unix/src/emacs/lisp; \ for file in calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url; do \ /d/software/windows/unix/src/emacs/lisp/../update-subdirs $file; \ done; Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url ./../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 \ /d/software/windows/unix/src/emacs/lisp/loaddefs.el)' \ -f batch-update-autoloads /d/software/windows/unix/src/emacs/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url Opening output file: no such file or directory, d:/d/software/windows/unix/src/emacs/lisp/loaddefs.el --8---cut here---end---8--- So there is a superfluous d: in front of the path. The problem will probably vanish if a drive:/dir/ syntax was used all along. But I don't know how to do this. As updating loaddefs.el fails, the loaddefs.el which remains in the lisp/ directory has the same contents as ldefs-boot.el which was copied by the bootstrap-clean target. Obviously ldefs-boot.el does not include autoloads for latexenc and Makefile mode stuff. For configuring and building Emacs I opened a DOS prompt entered the nt/ subdirectory, did a configure --with-gcc --prefix=d:/software/windows/unix/emacs and after that a make bootstrap All of this was done with recent versions of MSYS, MinGW and GnuWin32 libraries. The version of make is GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
The fact that you have no drive letters in the paths suggests to me that you are using cygwin or msys make, which corrupts DOS paths to look like unix paths in a way that only cygwin or msys tools can understand. This is not good behaviour for make, please try a different version. There are non-MSYS versions of mingw make available that use native paths. Ralf Angeli wrote: * Jason Rumney (2005-07-07) writes: Can you please try to debug what has caused this on your machine. I do not have this problem, and noone else has reported it either. Okay, I inserted a `sleep 60' at the end of the `autoloads' target of lisp/makefile and this is what I could observe during a `make bootstrap': --8---cut here---start-8--- make[1]: Entering directory `/d/software/windows/unix/src/emacs/lisp' /d/software/windows/unix/src/emacs/lisp/../update-subdirs /d/software/windows/unix/src/emacs/lisp; \ for file in calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url; do \ /d/software/windows/unix/src/emacs/lisp/../update-subdirs $file; \ done; Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url "./../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 \ "/d/software/windows/unix/src/emacs/lisp/loaddefs.el")' \ -f batch-update-autoloads /d/software/windows/unix/src/emacs/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url Opening output file: no such file or directory, d:/d/software/windows/unix/src/emacs/lisp/loaddefs.el --8---cut here---end---8--- So there is a superfluous "d:" in front of the path. The problem will probably vanish if a drive:/dir/ syntax was used all along. But I don't know how to do this. As updating loaddefs.el fails, the loaddefs.el which remains in the lisp/ directory has the same contents as ldefs-boot.el which was copied by the bootstrap-clean target. Obviously ldefs-boot.el does not include autoloads for latexenc and Makefile mode stuff. For configuring and building Emacs I opened a DOS prompt entered the nt/ subdirectory, did a configure --with-gcc --prefix=d:/software/windows/unix/emacs and after that a make bootstrap All of this was done with recent versions of MSYS, MinGW and GnuWin32 libraries. The version of make is GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Jason Rumney (2005-07-07) writes: The fact that you have no drive letters in the paths suggests to me that you are using cygwin or msys make, which corrupts DOS paths to look like unix paths in a way that only cygwin or msys tools can understand. From my former message: The version of make is GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys So yes, I am using MSYS make. There wasn't a warning about MSYS make in nt/INSTALL and the build process did not stop with an error, so I thought this would be safe. Now, after looking at URL:http://ourcomments.org/Emacs/w32-build-emacs.html which is mentioned in nt/INSTALL I actually saw that the very same problem I got is described there with a similar snippet of the make output. I have to apologize for not reading this web page before, but maybe one can spare other people this hassle by adding a warning about MSYS make to nt/INSTALL and let the build process abort if loaddefs.el cannot be updated. This is not good behaviour for make, please try a different version. There are non-MSYS versions of mingw make available that use native paths. Okay, MinGW comes with a mingw32-make.exe which identifies itself as mingw32-make --version GNU Make 3.80 Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: --8---cut here---start-8--- mingw32-make[1]: Entering directory `D:/software/windows/unix/src/emacs/lisp' D:/software/windows/unix/src/emacs/lisp/../update-subdirs D:/software/windows/unix/src/emacs/lisp; \ for file in calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url; do \ D:/software/windows/unix/src/emacs/lisp/../update-subdirs $file; \ done; Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url ./../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 \ D:/software/windows/unix/src/emacs/lisp/loaddefs.el)' \ -f batch-update-autoloads D:/software/windows/unix/src/emacs/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- The same happens if I rename mingw32-make.exe to make.exe. Via Google I could find the same error documented at URL:http://www.emacswiki.org/cgi-bin/emacs-en/BuildingTwentyOneThreeWThirtyTwoMingw together with some dubious workaround. I'm stumped. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
loaddefs.el on Windows incomplete
loaddefs.el in a Windows build checked out and compiled yesterday doesn't seem to include all autoloads. For example the autoloads for latexenc.el are missing. I suspect this is the cause for LaTeX files in a Windows build of Emacs being opened with a raw-text-dos coding system (which prevents character code conversion and therefore leads to other problems). -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
