* Problem building emacs from CVS under MSWindow due to CR/LF and addsection
@ 2008-10-10 5:48 Vincent Belaiche
2008-10-10 7:58 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Vincent Belaiche @ 2008-10-10 5:48 UTC (permalink / raw
To: emacs-devel
Dear all,
Sorry if this problem has been already submitted (actually I could not find
the bug search for emacs under savannah to check this).
I have tried to build the latest CVS version of Emacs, this morning under MSW.
After configuring with configure.bat under cmd.exe, I launched `make
bootstrap' from the MSYS bash shell.
I got the following problem
---------------
/c/Programme/GNU/emacs-install/emacs/nt>make bootstrap
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh.exe: -c: line 2: syntax error: unexpected end of file
', needed by `addsection'. Stop.
---------------
I edited the makefile under emacs, and I realized that there where plenty of
^M charaters which I all removed.
Thene the make could go a bit further. So I can imagine that the 1st problem I
met was due to addsection not understanding the CR characters.
Shall I fill in a bug ?
Best regard,
Vincent.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-10 5:48 Problem building emacs from CVS under MSWindow due to CR/LF and addsection Vincent Belaiche
@ 2008-10-10 7:58 ` Eli Zaretskii
2008-10-10 8:13 ` Juanma Barranquero
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2008-10-10 7:58 UTC (permalink / raw
To: Vincent Belaiche; +Cc: emacs-devel
> Date: Fri, 10 Oct 2008 07:48:49 +0200
> From: Vincent Belaiche <vincent.b.1@hotmail.fr>
>
> Sorry if this problem has been already submitted (actually I could not find
> the bug search for emacs under savannah to check this).
>
> I have tried to build the latest CVS version of Emacs, this morning under MSW.
>
> After configuring with configure.bat under cmd.exe, I launched `make
> bootstrap' from the MSYS bash shell.
>
> I got the following problem
>
> ---------------
> /c/Programme/GNU/emacs-install/emacs/nt>make bootstrap
> [Please ignore a syntax error on the next line - it is intentional]
> /bin/sh.exe: -c: line 1: unexpected EOF while looking for matching `"'
> /bin/sh.exe: -c: line 2: syntax error: unexpected end of file
> ', needed by `addsection'. Stop.
> ---------------
>
>
> I edited the makefile under emacs, and I realized that there where plenty of
> ^M charaters which I all removed.
>
> Thene the make could go a bit further. So I can imagine that the 1st problem I
> met was due to addsection not understanding the CR characters.
No, the problem is because the port of Make you were using does not
grok well the makefile with mixed NL and CR/LF line endings.
I understand that you were using the MSYS shell and Make ports for
building Emacs. The file nt/INSTALL does not list those as supported
build environments, and about MSYS it says this:
In addition, using 4NT as your shell is known to fail the build process,
at least for 4NT version 3.01. Use CMD.EXE, the default Windows shell,
instead. 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.
In general, a native Windows port of Make (available from the MinGW
site), not the MSYS Make, and stock Windows shell cmd.exe is all you
should need for a successful build.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-10 7:58 ` Eli Zaretskii
@ 2008-10-10 8:13 ` Juanma Barranquero
2008-10-10 9:00 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juanma Barranquero @ 2008-10-10 8:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
On Fri, Oct 10, 2008 at 09:58, Eli Zaretskii <eliz@gnu.org> wrote:
> building Emacs. The file nt/INSTALL does not list those as supported
> build environments, and about MSYS it says this:
>
> In addition, using 4NT as your shell is known to fail the build process,
> at least for 4NT version 3.01.
(Not related to the OP's question)
A few years ago, last I tested it, the only reason that 4NT/TCC failed
the build process is one line in nt/configure.bat:
if not "%$foo$%" == "123456789_123456789_123456789_123456789_123"
goto SmallEnv
because 4NT expands %$ (is an internal variable, like %1, etc.) so the
comparison is always false. If $foo$ were called foo$ 4NT would have
no trouble at all.
I mentioned that back then, but the idea of changing one character to
cater to non-free software was ill-received, IIRC.
Juanma
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-10 8:13 ` Juanma Barranquero
@ 2008-10-10 9:00 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2008-10-10 9:00 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
> Date: Fri, 10 Oct 2008 10:13:37 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
>
> A few years ago, last I tested it, the only reason that 4NT/TCC failed
> the build process is one line in nt/configure.bat:
>
> if not "%$foo$%" == "123456789_123456789_123456789_123456789_123"
> goto SmallEnv
>
> because 4NT expands %$ (is an internal variable, like %1, etc.) so the
> comparison is always false. If $foo$ were called foo$ 4NT would have
> no trouble at all.
>
> I mentioned that back then, but the idea of changing one character to
> cater to non-free software was ill-received, IIRC.
If you can test the change with current versions of 4NT, I don't mind
the change.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
@ 2008-10-12 19:09 Vincent Belaïche
2008-10-12 20:11 ` Eli Zaretskii
2008-10-12 22:21 ` Juanma Barranquero
0 siblings, 2 replies; 12+ messages in thread
From: Vincent Belaïche @ 2008-10-12 19:09 UTC (permalink / raw
To: eliz; +Cc: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 2170 bytes --]
Hello,
Thank you for your feedback. Sorry for the delay in answering.
So...
Actually, this $foo$ instead of foo$ does not seem to prevent building.
What really prevents building is the mixture of Unix and Dos end of line
in the makefile produced by configure.bat.
Replacing `$foo$' by `foo$' does not solve the issue which I am in.
In the attachment I have put this makefile, as you can see there is a
mixture of DOS and Unix style EOL. When I build with `makefile' the
build fails very soon. Now I edited `makefile' into
`makefile.woextractrlm' to remove all extra CTRL-M and I tried to build
with `-f makefile.woextractrlm' option.
It went quite further, but still it failed for a similar problem, in the
file uni-bidi.el the Local Variable section has some CTRL-M at end of
line, and this cause a load error. I included in the attached file a
file temp.el examplifying the problem.
Maybe configure.bat could be fixed by testing if sed is present on the
machine, and by filtering all the problematic files
by some `sed s/\r$//g' command.
I am wondering whether the issue with Local Variable is a bug by itself ?
Regards,
Vincent.
Eli Zaretskii a écrit :
>> Date: Fri, 10 Oct 2008 10:13:37 +0200
>> From: "Juanma Barranquero"
>> Cc: emacs-devel
>>
>> A few years ago, last I tested it, the only reason that 4NT/TCC failed
>> the build process is one line in nt/configure.bat:
>>
>> if not "%$foo$%" == "123456789_123456789_123456789_123456789_123"
>> goto SmallEnv
>>
>> because 4NT expands %$ (is an internal variable, like %1, etc.) so the
>> comparison is always false. If $foo$ were called foo$ 4NT would have
>> no trouble at all.
>>
>> I mentioned that back then, but the idea of changing one character to
>> cater to non-free software was ill-received, IIRC.
>>
>
> If you can test the change with current versions of 4NT, I don't mind
> the change.
>
>
>
>
>
_________________________________________________________________
Installez gratuitement les 20 émôticones Windows Live Messenger les plus fous ! Cliquez ici !
http://www.emoticones-messenger.fr/
[-- Attachment #1.2: Type: text/html, Size: 2506 bytes --]
[-- Attachment #2: issuewithWindows2000build.tgz --]
[-- Type: application/octet-stream, Size: 7678 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-12 19:09 Vincent Belaïche
@ 2008-10-12 20:11 ` Eli Zaretskii
2008-10-12 22:21 ` Juanma Barranquero
1 sibling, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2008-10-12 20:11 UTC (permalink / raw
To: Vincent Belaïche; +Cc: emacs-devel
> From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.b.1@hotmail.fr>
> CC: <emacs-devel@gnu.org>
> Date: Sun, 12 Oct 2008 21:09:46 +0200
>
> Actually, this $foo$ instead of foo$ does not seem to prevent building.
> What really prevents building is the mixture of Unix and Dos end of line
> in the makefile produced by configure.bat.
How is this related to the shell being used?
> In the attachment I have put this makefile, as you can see there is a
> mixture of DOS and Unix style EOL. When I build with `makefile' the
> build fails very soon. Now I edited `makefile' into
> `makefile.woextractrlm' to remove all extra CTRL-M and I tried to build
> with `-f makefile.woextractrlm' option.
I always check-out the CVS tree with -kb option, and thus I never have
these problems. Can you try that?
> Maybe configure.bat could be fixed by testing if sed is present on the
> machine, and by filtering all the problematic files
> by some `sed s/\r$//g' command.
Most Windows ports of Sed will not do with this what you want, because
they read input in "text" mode, where the CR characters are stripped
by low-level library I/O routines and never show in the Sed pattern
space.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-12 19:09 Vincent Belaïche
2008-10-12 20:11 ` Eli Zaretskii
@ 2008-10-12 22:21 ` Juanma Barranquero
1 sibling, 0 replies; 12+ messages in thread
From: Juanma Barranquero @ 2008-10-12 22:21 UTC (permalink / raw
To: Vincent Belaïche; +Cc: emacs-devel
On Sun, Oct 12, 2008 at 21:09, Vincent Belaïche <vincent.b.1@hotmail.fr> wrote:
> Actually, this $foo$ instead of foo$ does not seem to prevent building.
Of course not. That's why I said "(Not related to the OP's question)"...
Juanma
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
@ 2008-10-14 5:01 Vincent Belaïche
0 siblings, 0 replies; 12+ messages in thread
From: Vincent Belaïche @ 2008-10-14 5:01 UTC (permalink / raw
To: eliz; +Cc: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 2400 bytes --]
Eli Zaretskii a écrit :
>> From: =?iso-8859-1?Q?Vincent_Bela=EFche?=
>> CC:
>> Date: Sun, 12 Oct 2008 21:09:46 +0200
>>
>> Actually, this $foo$ instead of foo$ does not seem to prevent building.
>> What really prevents building is the mixture of Unix and Dos end of line
>> in the makefile produced by configure.bat.
>>
>
> How is this related to the shell being used?
>
I launch `configure.bat' under cmd.exe
Then I launched `mingw32-make.exe -f makefile.woextractrlm bootstrap'
both under MSYS bash and under cmd.exe, and I get the same result in
both cases.
Note that changing the shell between configure and build is not an odd
idea of mine, but it is something that is kind of suggested as possible
in the nt/INSTALL file :
-----
from a Unixy shell prompt:
cmd /c configure.bat
-----
>
>> In the attachment I have put this makefile, as you can see there is a
>> mixture of DOS and Unix style EOL. When I build with `makefile' the
>> build fails very soon. Now I edited `makefile' into
>> `makefile.woextractrlm' to remove all extra CTRL-M and I tried to build
>> with `-f makefile.woextractrlm' option.
>>
>
> I always check-out the CVS tree with -kb option, and thus I never have
> these problems. Can you try that?
>
>
I will do this, and make you know
>> Maybe configure.bat could be fixed by testing if sed is present on the
>> machine, and by filtering all the problematic files
>> by some `sed s/\r$//g' command.
>>
>
> Most Windows ports of Sed will not do with this what you want, because
> they read input in "text" mode, where the CR characters are stripped
> by low-level library I/O routines and never show in the Sed pattern
> space.
>
>
>
I have just made a trial, and it works. I prepared a file temp.in.txt
with a mixture of DOSy and UNIXy EOLs, and I run the one-liner:
under unixy shell:
sed "s/\r?$//" temp.in.txt> unix.temp.ou.txt
under dos shell:
sed "s/\r?$//" temp.in.txt> dos.temp.ou.txt
After this, both unix.temp.ou.txt and dos.temp.ou.txt have a uniform end
of line. Please see the attached files.
>
>
_________________________________________________________________
Email envoyé avec Windows Live Hotmail. Dites adieux aux spam et virus, passez à Hotmail ! C'est gratuit !
http://www.windowslive.fr/hotmail/default.asp
[-- Attachment #1.2: Type: text/html, Size: 2776 bytes --]
[-- Attachment #2: temp.in.txt --]
[-- Type: application/octet-stream, Size: 195 bytes --]
-*- coding: iso-8859-1-unix -*-
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
[-- Attachment #3: unix.temp.ou.txt --]
[-- Type: application/octet-stream, Size: 206 bytes --]
-*- coding: iso-8859-1-unix -*-
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
[-- Attachment #4: dos.temp.ou.txt --]
[-- Type: application/octet-stream, Size: 204 bytes --]
-*- coding: iso-8859-1-unix -*-
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines without CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
Lines with CR
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
@ 2008-10-19 19:13 Vincent Belaïche
2008-10-20 14:55 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Vincent Belaïche @ 2008-10-19 19:13 UTC (permalink / raw
To: eliz; +Cc: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 1083 bytes --]
Hello,
> I always check-out the CVS tree with -kb option, and thus I never have
> these problems. Can you try that?
>
>
I have tried it and it goes far beyond what it used to. However I get a
lot of errors like this
Error: charsets directory (c:/Programme/GNU/Emacs/etc/charsets) does not
exist.
`c:/Programme/GNU/Emacs' is the prefix with I supplied. I am surprised
by this error, because I thought that the prefix directory is not tested
during the build (make bootstrap) but only during the installation (make
install). Currently c:/Programme/GNU/Emacs contains version 22.2.1 on my
machine, and I made the build from within Emacs.
Final error is this:
mingw32-make[1]: *** No rule to make target
`../lisp/language/european.elc', needed by `DOC'. Stop.
Best regards,
Vincent.
I attached the log for information.
_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp
[-- Attachment #1.2: Type: text/html, Size: 1272 bytes --]
[-- Attachment #2: build20081016.log.gz --]
[-- Type: application/octet-stream, Size: 29541 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-19 19:13 Vincent Belaïche
@ 2008-10-20 14:55 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2008-10-20 14:55 UTC (permalink / raw
To: Vincent Belaïche; +Cc: emacs-devel
> From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.b.1@hotmail.fr>
> CC: <emacs-devel@gnu.org>
> Date: Sun, 19 Oct 2008 21:13:19 +0200
>
> > I always check-out the CVS tree with -kb option, and thus I never have
> > these problems. Can you try that?
> >
> >
> I have tried it and it goes far beyond what it used to. However I get a
> lot of errors like this
>
> Error: charsets directory (c:/Programme/GNU/Emacs/etc/charsets) does not
> exist.
>
> `c:/Programme/GNU/Emacs' is the prefix with I supplied. I am surprised
> by this error, because I thought that the prefix directory is not tested
> during the build (make bootstrap) but only during the installation (make
> install). Currently c:/Programme/GNU/Emacs contains version 22.2.1 on my
> machine, and I made the build from within Emacs.
Do you have EMACSDATA variable set in the environment or in the
Registry? If so, remove that variable and try again. This variable
overrides the default place where Emacs looks for its data files (the
value of `data-directory'), including the charsets directory.
> Final error is this:
>
> mingw32-make[1]: *** No rule to make target
> `../lisp/language/european.elc', needed by `DOC'. Stop.
That's because european.el failed to byte-compile, probably due to the
problems with charsets directory.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
@ 2008-10-20 18:33 Vincent Belaïche
2008-10-20 23:50 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Vincent Belaïche @ 2008-10-20 18:33 UTC (permalink / raw
To: eliz; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
Hello,
> Do you have EMACSDATA variable set in the environment or in the
> Registry? If so, remove that variable and try again. This variable
> overrides the default place where Emacs looks for its data files (the
> value of `data-directory'), including the charsets directory.
>
>
FYI,
Actually I have not EMACSDATA nor in my environment variables, nor in
the registrty. If I open an MSDOS console and I type
echo %EMACSDATA%
The answer is just %EMACSDATA%.
But the thing is that I made the build from inside Emacs, and there
EMACSDATA is set to the current Emacs etc directory (even though I do
not set EMACSDATA in my init file)...
I will try again with typing SET EMACSDATA= before building.
I don't think that it is strange to build emacs from inside emacs, as
long as you just build, not install. This is what I did.
VBR,
Vincent.
PS: Maybe there should be some robustness against this situation in the
makefile, something testing INSIDE_EMACS along with EMACSDATA.
_________________________________________________________________
Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger !
http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx
[-- Attachment #2: Type: text/html, Size: 1457 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection
2008-10-20 18:33 Vincent Belaïche
@ 2008-10-20 23:50 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2008-10-20 23:50 UTC (permalink / raw
To: Vincent Belaïche; +Cc: emacs-devel
> From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.b.1@hotmail.fr>
> CC: <emacs-devel@gnu.org>
> Date: Mon, 20 Oct 2008 20:33:28 +0200
>
> Actually I have not EMACSDATA nor in my environment variables, nor in
> the registrty. If I open an MSDOS console and I type
>
> echo %EMACSDATA%
>
> The answer is just %EMACSDATA%.
>
> But the thing is that I made the build from inside Emacs, and there
> EMACSDATA is set to the current Emacs etc directory (even though I do
> not set EMACSDATA in my init file)...
Emacs on Windows sets EMACSDATA (and also EMACSLOADPATH, EMACSDOC and
EMACSPATH) at startup, to account for the possible move of the
installation tree between the build and the run time. This is
because, unlike on Unix, the Windows build does not fix the
installation directory at build time.
> I will try again with typing SET EMACSDATA= before building.
I think "M-x setenv" would be better.
> I don't think that it is strange to build emacs from inside emacs, as
> long as you just build, not install. This is what I did.
No, it's not strange.
> PS: Maybe there should be some robustness against this situation in the
> makefile, something testing INSIDE_EMACS along with EMACSDATA.
That's not a good idea: some Makefile's set EMACS* variables
themselves. I will try to find another way to avoid pollution of
process-environment, though. Thanks for pointing this out.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-10-20 23:50 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-10 5:48 Problem building emacs from CVS under MSWindow due to CR/LF and addsection Vincent Belaiche
2008-10-10 7:58 ` Eli Zaretskii
2008-10-10 8:13 ` Juanma Barranquero
2008-10-10 9:00 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2008-10-12 19:09 Vincent Belaïche
2008-10-12 20:11 ` Eli Zaretskii
2008-10-12 22:21 ` Juanma Barranquero
2008-10-14 5:01 Vincent Belaïche
2008-10-19 19:13 Vincent Belaïche
2008-10-20 14:55 ` Eli Zaretskii
2008-10-20 18:33 Vincent Belaïche
2008-10-20 23:50 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.