From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Vincent_Bela=EFche?= Newsgroups: gmane.emacs.devel Subject: Re: Problem building emacs from CVS under MSWindow due to CR/LF and addsection Date: Tue, 14 Oct 2008 07:01:46 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_7b19b146-aac0-4c89-9a4a-892383a771bc_" X-Trace: ger.gmane.org 1223960536 3643 80.91.229.12 (14 Oct 2008 05:02:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Oct 2008 05:02:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 14 07:03:07 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kpc3m-0008KQ-7b for ged-emacs-devel@m.gmane.org; Tue, 14 Oct 2008 07:03:06 +0200 Original-Received: from localhost ([127.0.0.1]:53303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kpc2h-0002CT-So for ged-emacs-devel@m.gmane.org; Tue, 14 Oct 2008 01:01:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kpc2c-0002CE-2N for emacs-devel@gnu.org; Tue, 14 Oct 2008 01:01:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kpc2a-0002Bu-Fv for emacs-devel@gnu.org; Tue, 14 Oct 2008 01:01:52 -0400 Original-Received: from [199.232.76.173] (port=59926 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kpc2a-0002Br-9x for emacs-devel@gnu.org; Tue, 14 Oct 2008 01:01:52 -0400 Original-Received: from blu0-omc2-s21.blu0.hotmail.com ([65.55.111.96]:18647) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kpc2W-00082Q-HW; Tue, 14 Oct 2008 01:01:48 -0400 Original-Received: from BLU104-W12 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 22:01:47 -0700 X-Originating-IP: [90.32.0.17] Importance: Normal X-OriginalArrivalTime: 14 Oct 2008 05:01:47.0388 (UTC) FILETIME=[F5DD23C0:01C92DB9] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104509 --_7b19b146-aac0-4c89-9a4a-892383a771bc_ Content-Type: multipart/alternative; boundary="_ce478035-d323-4515-8093-c81050e2462a_" --_ce478035-d323-4515-8093-c81050e2462a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eli Zaretskii a =E9crit : >> From: =3D?iso-8859-1?Q?Vincent_Bela=3DEFche?=3D=20 >> CC:=20 >> Date: Sun=2C 12 Oct 2008 21:09:46 +0200 >> >> Actually=2C this $foo$ instead of foo$ does not seem to prevent building= .=20 >> What really prevents building is the mixture of Unix and Dos end of line= =20 >> in the makefile produced by configure.bat. >> =20 > > How is this related to the shell being used? > =20 I launch `configure.bat' under cmd.exe Then I launched `mingw32-make.exe -f makefile.woextractrlm bootstrap'=20 both under MSYS bash and under cmd.exe=2C and I get the same result in=20 both cases. Note that changing the shell between configure and build is not an odd=20 idea of mine=2C but it is something that is kind of suggested as possible=20 in the nt/INSTALL file : ----- from a Unixy shell prompt: cmd /c configure.bat ----- > =20 >> In the attachment I have put this makefile=2C as you can see there is a= =20 >> mixture of DOS and Unix style EOL. When I build with `makefile' the=20 >> build fails very soon. Now I edited `makefile' into=20 >> `makefile.woextractrlm' to remove all extra CTRL-M and I tried to build= =20 >> with `-f makefile.woextractrlm' option. >> =20 > > I always check-out the CVS tree with -kb option=2C and thus I never have > these problems. Can you try that? > > =20 I will do this=2C and make you know >> Maybe configure.bat could be fixed by testing if sed is present on the=20 >> machine=2C and by filtering all the problematic files >> by some `sed s/\r$//g' command. >> =20 > > Most Windows ports of Sed will not do with this what you want=2C because > they read input in "text" mode=2C where the CR characters are stripped > by low-level library I/O routines and never show in the Sed pattern > space. > > > =20 I have just made a trial=2C and it works. I prepared a file temp.in.txt=20 with a mixture of DOSy and UNIXy EOLs=2C 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=2C both unix.temp.ou.txt and dos.temp.ou.txt have a uniform end= =20 of line. Please see the attached files. > > =20 _________________________________________________________________ Email envoy=E9 avec Windows Live Hotmail. Dites adieux aux spam et virus=2C= passez =E0 Hotmail=A0! C'est gratuit ! http://www.windowslive.fr/hotmail/default.asp= --_ce478035-d323-4515-8093-c81050e2462a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eli Zaretskii a =E9crit :
>> From: =3D?iso-8859-1?Q?Vincent_Bela=3DEFche= ?=3D
>> CC:
>> Date: S= un=2C 12 Oct 2008 21:09:46 +0200
>>
>> Actually=2C this $foo$ instead= of foo$ does not seem to prevent building.
>> What really prevents bui= lding is the mixture of Unix and Dos end of line
>> in the makefile pro= duced by configure.bat.
>>
>
> How is this related to the she= ll being used?
>
I launch `configure.bat' under cmd.exe
Then I = launched `mingw32-make.exe -f makefile.woextractrlm bootstrap'
both un= der MSYS bash and under cmd.exe=2C and I get the same result in
both ca= ses.

Note that changing the shell between configure and build is not= an odd
idea of mine=2C but it is something that is kind of suggested a= s possible
in the nt/INSTALL file :
-----
from a Unixy shell= prompt:

cmd /c configure.bat
-----

>
>> In t= he attachment I have put this makefile=2C 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.woextr= actrlm' to remove all extra CTRL-M and I tried to build
>> with `-f mak= efile.woextractrlm' option.
>>
>
> I always check-out the CVS= tree with -kb option=2C and thus I never have
> these problems. Can yo= u try that?
>
>
I will do this=2C and make you know
>> Maybe= configure.bat could be fixed by testing if sed is present on the
>> ma= chine=2C 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=2C because
> they read input in "text" mode=2C w= here the CR characters are stripped
> by low-level library I/O routines = and never show in the Sed pattern
> space.
>
>
>
I have j= ust made a trial=2C and it works. I prepared a file temp.in.txt
with a = mixture of DOSy and UNIXy EOLs=2C and I run the one-liner:

under uni= xy 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= =2C both unix.temp.ou.txt and dos.temp.ou.txt have a uniform end
of lin= e. Please see the attached files.



>
>



Qui vous permet d'enregistrer la TV sur votre PC et lire vos emails = sur votre mobile=A0? la r=E9ponse en vid=E9o la r=E9ponse en vid= =E9o = --_ce478035-d323-4515-8093-c81050e2462a_-- --_7b19b146-aac0-4c89-9a4a-892383a771bc_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="temp.in.txt" LSotIGNvZGluZzogaXNvLTg4NTktMS11bml4IC0qLQoKTGluZXMgd2l0aG91dCBDUgpMaW5lcyB3 aXRob3V0IENSCkxpbmVzIHdpdGhvdXQgQ1IKTGluZXMgd2l0aG91dCBDUgpMaW5lcyB3aXRob3V0 IENSCgpMaW5lcyB3aXRoIENSDQpMaW5lcyB3aXRoIENSDQpMaW5lcyB3aXRoIENSDQpMaW5lcyB3 aXRoIENSDQpMaW5lcyB3aXRoIENSDQoK --_7b19b146-aac0-4c89-9a4a-892383a771bc_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="unix.temp.ou.txt" LSotIGNvZGluZzogaXNvLTg4NTktMS11bml4IC0qLQ0KDQpMaW5lcyB3aXRob3V0IENSDQpMaW5l cyB3aXRob3V0IENSDQpMaW5lcyB3aXRob3V0IENSDQpMaW5lcyB3aXRob3V0IENSDQpMaW5lcyB3 aXRob3V0IENSDQoNCkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1IN CkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1INCg0KDQo= --_7b19b146-aac0-4c89-9a4a-892383a771bc_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dos.temp.ou.txt" LSotIGNvZGluZzogaXNvLTg4NTktMS11bml4IC0qLQ0KDQpMaW5lcyB3aXRob3V0IENSDQpMaW5l cyB3aXRob3V0IENSDQpMaW5lcyB3aXRob3V0IENSDQpMaW5lcyB3aXRob3V0IENSDQpMaW5lcyB3 aXRob3V0IENSDQoNCkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1IN CkxpbmVzIHdpdGggQ1INCkxpbmVzIHdpdGggQ1INCg0K --_7b19b146-aac0-4c89-9a4a-892383a771bc_--