Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Vincent Belaïche]

[-- 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 --]

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Eli Zaretskii]

> 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.

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Juanma Barranquero]

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

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Vincent Belaïche]

[-- 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 --]

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Eli Zaretskii]

> 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.

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Vincent Belaïche]

[-- 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 --]

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Eli Zaretskii]

> 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.

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Vincent Belaïche]

[-- 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

Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Vincent Belaiche]

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.

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Eli Zaretskii]

> 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.

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Juanma Barranquero]

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

Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection

[Eli Zaretskii]

> 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.