From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?B?VmluY2VudCBCZWxh72NoZQ==?= Newsgroups: gmane.emacs.devel,gmane.emacs.semantic Subject: RE: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1 Date: Sat, 6 Oct 2012 23:41:21 +0200 Message-ID: References: <80627pfvx8.fsf@gmail.com>, , <87k3vhesof.fsf@randomsample.de>, , <877grgdmcd.fsf@randomsample.de>, , <87mx0bcioh.fsf@randomsample.de>, , <87sj9yb4kw.fsf@randomsample.de>, , <83obkka8c8.fsf@gnu.org>, , <83mx038fm8.fsf@gnu.org>, , <83zk41730h.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_da988ecf-14c7-4496-a3f8-ec2d56131a1a_" X-Trace: ger.gmane.org 1349559696 27253 80.91.229.3 (6 Oct 2012 21:41:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2012 21:41:36 +0000 (UTC) Cc: "deng@randomsample.de" , "cedet-semantic@lists.sourceforge.net" , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 06 23:41:41 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TKc7v-0001DA-Ls for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2012 23:41:40 +0200 Original-Received: from localhost ([::1]:49583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKc7p-0001Rp-Ry for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2012 17:41:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKc7l-0001Rf-Kd for emacs-devel@gnu.org; Sat, 06 Oct 2012 17:41:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKc7i-0003BL-Rz for emacs-devel@gnu.org; Sat, 06 Oct 2012 17:41:29 -0400 Original-Received: from dub0-omc2-s5.dub0.hotmail.com ([157.55.1.144]:22344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKc7f-00039e-1D; Sat, 06 Oct 2012 17:41:23 -0400 Original-Received: from DUB102-W15 ([157.55.1.136]) by dub0-omc2-s5.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 6 Oct 2012 14:41:21 -0700 X-Originating-IP: [92.135.119.148] Importance: Normal In-Reply-To: <83zk41730h.fsf@gnu.org> X-OriginalArrivalTime: 06 Oct 2012 21:41:21.0650 (UTC) FILETIME=[53860520:01CDA40B] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP4, XP SP1+ X-Received-From: 157.55.1.144 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154144 gmane.emacs.semantic:3027 Archived-At: --_da988ecf-14c7-4496-a3f8-ec2d56131a1a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Feedback inserted below: > Date: Fri=2C 5 Oct 2012 10:10:38 +0200 > From: eliz@gnu.org > Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with e= macs 24.1 > To: vincent.b.1@hotmail.fr > CC: cedet-semantic@lists.sourceforge.net=3B deng@randomsample.de=3B emacs= -devel@gnu.org >=20 > > From: Vincent Bela=EFche > > CC: "cedet-semantic@lists.sourceforge.net" > > =2C emacs-devel > > Date: Fri=2C 5 Oct 2012 07:18:53 +0200 > >=20 > > Thank you Eli for your kind answer. I tried it with the mingw32-make a = link to which you have sent to me. It is correct that it does not use MSYS = paths like /c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loa= ddefs.el=2C but the same kind of path that pwd -W outputs=2C i.e. c:/Progra= mme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el for the sam= e file. EMACS is supposed to understand that kind of path. However that sti= ll does not work: >=20 > My crystal ball says that pwd is an MSYS program. IOW=2C you still have > MSYS's /bin directory on your general PATH=2C=20 Your crystal ball is perfectly correct > and those MSYS tools=2C > especially Bash=2C are being invoked by the MinGW Make. >=20 > If you are invoking Make from the MSYS Bash console window=2C don't=3B > invoke it from a regular cmd window instead. =20 I tried both actually=2C but=2C true=2C MSYS's /bin was in the PATH in both= cases > If you added MSYS's /bin > directory to your PATH such that even the cmd window gets that PATH=2C > edit your environment variables and remove the MSYS /bin directory > from the PATH. Then these problems will go away=2C and you will be > faced only with real problems: the Unixy features used by the Makefile > that don't work on Windows. These you will have to solve=2C but at > least you will be fighting known issues. Well=2C call this the "real problems" if you like=2C I am slightly sceptica= l on what the real problem really is=2C most Makefiles I have seen in my li= fe are delegating some file manipulation tasks to some bash shell. Even the= documentation of Make is most of the time doing this assumption --- e.g. s= ee those `rm ...' in the documentation of `clean' targets. The reason why so is that GNU make may have lots of thing in its sleeve=2C = but=2C AFAIK=2C it does not have builtins to do basical file manipation fun= ctions. So it has to resort to some shell call=2C most of the time Bash.=20 In contrast to GNU make=2C ant has the filterset=2C delete=2C mkdir=2C and= copy tasks. So one does not need to delegate those basic things to any she= ll=2C and build.xml files are made more portable this way. Considering CEDET I tried what you said=2C I wrote an MSDOS batch file with= this content (the first line ensures that I have both mingw32-make and ema= cs in the PATH=2C but no more : ------- begin -------SET PATH=3Dc:\msys\1.0\mingw\bin=3Bc:\Programme\GNU\em= acs-24.1\bin SET RM=3DDEL CD cedet mingw32-make CD .. ------- end -------=20 and that failed quite soon with this output: ------- begin ------- C:\Programme\GNU\installation\cedet-install>SET PATH=3Dc:\msys\1.0\mingw\bi= n=3Bc:\Programme\GNU\emacs-24.1\bin=20 C:\Programme\GNU\installation\cedet-install>SET RM=3DDEL=20 C:\Programme\GNU\installation\cedet-install>CD cedet=20 C:\Programme\GNU\installation\cedet-install\cedet>mingw32-make Emacs version: 24.1.1 nil on windows-nt=20 Removing loaddefs.el files from subprojects. -f =E9tait inattendu. mingw32-make: *** [clean-autoloads] Error 255 C:\Programme\GNU\installation\cedet-install\cedet>CD ..=20 ------- end ------- As far as I can understand this failure happened when = this statement was met: @$(foreach proj=2C$(PROJECTS_AUTOLOADS)=2Ccd $(CURDIR)/$(proj) && if [ = -f $(LOADDEFS) ]=3Bthen $(RM) -f $(LOADDEFS)=3Bfi=3B) Quite surprising DOS does not bark on `cd $(CURDIR)/$(proj)' despite the `= /' inside it=2C but the `if [ -f ... ]=3B ....=3B fi' instead of `IF EXIST = ... ( ... )' was a bit too much asking of DOS / Bash similarity. It just seems to me quite challenging to write Makefile in a portable way w= hile --- sorry for repeating myself --- GNU Make is missing those tasks cal= led filterset=2C delete=2C mkdir=2C and copy in ant.GNU Make simply does no= t have these things built-in=2C this is why most Makefile delegate them to = Bash=2C and one can see find=2C rm=2C mkdir and cp bash commands instead=2C= which means that you get into troubles when you want to use this Makefile = on a plaform without Bash.=20 Here we are talking on doing macro definition to have some portable tasks l= ike filterset=2C delete=2C mkdir=2C and copy in ant --- i.e. not the same = macro definition in DOS and in a unixy shell=2C but that reasoning is quite= unstatisfactory=2C because that means that every time you are considering = a new shell you will need to create again such a set of macros --- or bette= r=2C user defined function that one would $(call ...). So=2C you may argue that the real problem is that Makefile call some bash c= ommands=2C but I am more opinionated that the real problem is that GNU Make= is missing the builtin features that would allow one to do without those b= ash command in the statements in a standard way=2C and without user defined= macros/function to ensure portability.=20 >=20 > > Debugger entered--Lisp error: (file-error "Opening output file" "no suc= h file or directory" "d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c=3Bc:= msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el") > ^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > See this nonsense? That's MSYS file syntax conversion in action. [... SNIP ...] >=20 Thank you again for your commenting on it: I must admit that I was not awar= e that MSYS was so invasive in preprocessing arguments like that=2C I could= not even imagine it=2C I had thought that emacs was the one doing those ki= nd of argument preprocessing. That is all the more surprising that the string that is transformed is with= in some simple-quotes. > > What happens is that path `c:/Programme/GNU/installation/cedet-install= /cedet/lisp/cedet/loaddefs.el' in the command line transformed by EMACS int= o `c=3Bc:\msys\1.0\Programme\GNU\installation\cedet-install\cedet\lisp\ced= et\loaddefs.el'. >=20 > Yes. This is what MSYS does=2C and it does that for a good reason. The > problem is that the algorithms MSYS applies for this conversion > misfire when the program being invoked has its own ideas about the > syntax of the command-line arguments. This is one such case. > (Invoking a natively-compiled Sed is another prominent case where the > MSYS file-name conversion badly misfires.)> Ok=2C I see=2C unless if you do the 's/find-this/replace-by-that/g' with so= me other character than `/'=2C e.g. like that 's!find-this!replace-by-that!= g' =20 But your comment is quite interesting: would that mean that if emacs was co= mpiled to be an MSYS application then it would be able to prevent MSYS from= doing mischiefs by telling to MSYS which argument is supposed to be a path= and which is not ? I mean that EMACS people boasting that EMACS is ported on most known platfo= rm seem not to consider MSYS as a platform on its own=2C i.e. it seems that= EMACS Win32 port does not test at all whether MSYSTEM environment variabl= e is set to MSYS or to MINGW32=2C nor whether OSTYPE is set to msys ... >=20 > > Probably the reason for doing that is quite valid: the path should have= been ` c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\loadde= fs.el' in the first place. >=20 > No. (Btw=2C using "D:/foo/bar" syntax of file names is perfectly OK on > Windows=2C because the Windows file I/O APIs understand forward slashes > very well=2C but that's not the issue here.) The problem is elsewhere: > this command-line argument is _not_ a file name. It is a Lisp string > that will be interpreted as a file name by Emacs. But MSYS does not > (and cannot) have the slightest idea about valid syntax of Lisp > strings=3B in particular=2C it doesn't know that a backslash in a Lisp > string needs to be doubled. So it ruins the command line by its > simplistic conversion.>=20 > >My thought are rather that is it hard to write makefile that are portabl= e because GNU Make is lacking the following features: > >=20 > >=20 > > - a predefined variable=2C e.g. $(FS) expanding to the file separator= =2C i.e. \ for MSWindows and / for Unixy shell >=20 > Why do you need this? As I said=2C Windows programs=2C Emacs included=2C > understand forward slashes in file names quite well. The only one > that might have problems is cmd.exe=2C but you should not need to invoke > cmd.exe's commands too much=2C if at all. =20 Well=2C for instance=2C as far as I remember DEL is an MSDOS internal comma= nd=2C so at least for all the clean and such like targets --- which quite c= ommon in any Makefile --- you need those backslash and not forward-slash=2C= if you assume that you have only MSDOS to rely on=2C and not MSYS in your = path=2C or at least RM variable defined to MSYS's rm.exe > And if you do need internal > cmd commands=2C there are the 'subst' and 'patsubst' Make functions you > can use to convert forward slashes to backslashes on the cmd command > lines. >=20 But then that kind of mean using the same sort of tricks to which I resorte= d to compile with MSYS. I was also doing those subst to have the backslashe= s in the first place and be sure that no problem would happen become some S= W (be it MSYS or EMACS) would do some mistake in badly converting forward s= lashed to backward slashes > Also=2C do you know that Make converts all environment variables to Make > variables=2C and expands them? >=20 > > - a predefined variable=2C e.g. $(CFS)=2C expanding to the file separat= or within a C-string-like environment=2C i.e. \\ for MSWindows and / for Un= ixy shell=20 >=20 > Again=2C you should not need this at all. This problem does not exist=2C > as long as you invoke Emacs from the Makefile. >=20 > > - a function=2C e.g. $(pathconvert ...) to convert a path name in the t= he Unixy like format that make internally uses with wildcards and $(abspath= ...) returned value into the format used on the platform where make is run= ning=2C i.e. in my case `c:/Programme/GNU/installation/cedet-install/cedet= /lisp/cedet/loaddefs.el' would be converted to `c:\Programme\GNU\installat= ion\cedet-install\cedet\lisp\cedet\loaddefs.el' >=20 > Not needed=2C see above. >=20 > > - and a function=2C e.g. $(cpathconvert ...) which would do the same th= ing but with output to go within some C-string-like environement=2C i.e. in= my case=20 > > `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.= el' would be converted to `c:\\Programme\\GNU\\installation\\cedet-instal= l\\cedet\\lisp\\cedet\\loaddefs.el' >=20 > Again=2C not needed. >=20 > > Without those basic things=2C one has no other resorts than the kind o= f tricks which I played to make the Makefile platform independent=2C and wh= ich=2C I agree=2C may be fragile=2C though working ones. >=20 > You will have to explain why you at all need these basic things. >=20 > > Please note that this is why I mentioned ant: in contrast to GNU Make= =2C ant has that sort of tricks that allow to do path name manipulations. >=20 > GNU Make has enough up its sleeve for this job=2C and many similar ones= =2C > believe me. >=20 I would be more than quite happy to believe you=2C but it seems that I don'= t have enough expertize in GNU make for having this belief. And=2C this lac= k of expertize --- of lack of things up the sleeve of GNU make=2C let us se= e --- is not just mine: see it=2C CEDET's Makefile's are not portable to DO= S according to your criterion that the real problem is the use of Bash comm= ands. E.g. CEDET Makefile's call bash specific command `if [ -f .... ]=3B t= hen ... fi'. But surely CEDET people who created EDE know far more about wr= iting Makefiles than I do. However CEDET's Makefile could be portable to Wi= n32 if you take it for granted that GNU Make cannot leave without some Unix= y shell nearby --- so MSYS under MSWindow ---=2C and therefore that the onl= y remaining issue is path manipulation. Hence the FS=2C CFS=2C pathconvert = and cpathconvert which I was suggesting. VBR=2C Vincent. >=20 >=20 = --_da988ecf-14c7-4496-a3f8-ec2d56131a1a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Feedback inserted below:

>=3B Date: Fri=2C 5 Oct 2012 10:10:3= 8 +0200
>=3B From: eliz@gnu.org
>=3B Subject: Re: [cedet-semantic= ] Latest CEDET on BZR does not compile with emacs 24.1
>=3B To: vincen= t.b.1@hotmail.fr
>=3B CC: cedet-semantic@lists.sourceforge.net=3B deng= @randomsample.de=3B emacs-devel@gnu.org
>=3B
>=3B >=3B From: V= incent Bela=EFche <=3Bvincent.b.1@hotmail.fr>=3B
>=3B >=3B CC: "= cedet-semantic@lists.sourceforge.net"
>=3B >=3B <=3Bcedet-semanti= c@lists.sourceforge.net>=3B=2C emacs-devel <=3Bemacs-devel@gnu.org>= =3B
>=3B >=3B Date: Fri=2C 5 Oct 2012 07:18:53 +0200
>=3B >= =3B
>=3B >=3B Thank you Eli for your kind answer. I tried it with t= he mingw32-make a link to which you have sent to me. It is correct that it = does not use MSYS paths like /c/Programme/GNU/installation/cedet-install/ce= det/lisp/cedet/loaddefs.el=2C but the same kind of path that pwd -W outputs= =2C i.e. c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loadd= efs.el for the same file. EMACS is supposed to understand that kind of path= . However that still does not work:
>=3B
>=3B My crystal ball sa= ys that pwd is an MSYS program. IOW=2C you still have
>=3B MSYS's /bi= n directory on your general PATH=2C

Your crystal = ball is perfectly correct

>=3B and those MSYS to= ols=2C
>=3B especially Bash=2C are being invoked by the MinGW Make.>=3B
>=3B If you are invoking Make from the MSYS Bash console wind= ow=2C don't=3B
>=3B invoke it from a regular cmd window instead.

I tried both actually=2C but=2C true=2C MSYS's /bin w= as in the PATH in both cases

>=3B If you added M= SYS's /bin
>=3B directory to your PATH such that even the cmd window g= ets that PATH=2C
>=3B edit your environment variables and remove the M= SYS /bin directory
>=3B from the PATH. Then these problems will go aw= ay=2C and you will be
>=3B faced only with real problems: the Unixy fe= atures used by the Makefile
>=3B that don't work on Windows. These yo= u will have to solve=2C but at
>=3B least you will be fighting known i= ssues.

Well=2C call this the "real problems" if yo= u like=2C I am slightly sceptical on what the real problem really is=2C mos= t Makefiles I have seen in my life are delegating some file manipulation ta= sks to some bash shell. Even the documentation of Make is most of the time = doing this assumption --- e.g. see those `rm ...' in the documentation of `= clean' targets.

The reason why so is that GNU make= may have lots of thing in its sleeve=2C but=2C AFAIK=2C it does not have b= uiltins to do basical file manipation functions. So it has to resort to som= e shell call=2C most of the time Bash. =3B

In = contrast to GNU make=2C ant has the  =3Bfilterset=2C delete=2C mkdir=2C= and copy tasks. So one does not need to delegate those basic things to any= shell=2C and build.xml files are made more portable this way.
Considering CEDET I tried what you said=2C I wrote an MSDOS ba= tch file with this content (the first line ensures that I have both mingw32= -make and emacs in the PATH=2C but no more :

-----= -- begin -------
SET PATH=3Dc:\msys\1.0\mingw\bin=3Bc:\Programme\= GNU\emacs-24.1\bin
SET RM=3DDEL

CD cedet
mingw32-make

C= D ..
 =3B------- end ------- =3B

=
and that failed quite soon with this output:
------- begin -------
C:\Programme\GNU\installation\cedet-install>=3BSET PATH=3Dc:\msys\1.= 0\mingw\bin=3Bc:\Programme\GNU\emacs-24.1\bin

C:\Programme\GNU\inst= allation\cedet-install>=3BSET RM=3DDEL

C:\Programme\GNU\installat= ion\cedet-install>=3BCD cedet

C:\Programme\GNU\installation\cedet= -install\cedet>=3Bmingw32-make
Emacs version: 24.1.1 nil on windows-nt=
Removing loaddefs.el files from subprojects.
-f =E9tait inattendu.<= br>mingw32-make: *** [clean-autoloads] Error 255

C:\Programme\GNU\in= stallation\cedet-install\cedet>=3BCD ..
 =3B------- end -------&n= bsp=3B
As far as I can understand this failure happened whe= n this statement was met:

 =3B  =3B @$(for= each proj=2C$(PROJECTS_AUTOLOADS)=2Ccd $(CURDIR)/$(proj) &=3B&=3B if = [ -f $(LOADDEFS) ]=3Bthen $(RM) -f $(LOADDEFS)=3Bfi=3B)

Quite surprising DOS does not bark on `cd =3B $(CURDIR)/$(proj)' = despite the `/' inside it=2C but the `if [ -f ... ]=3B ....=3B fi' instead = of `IF EXIST ... ( ... )' was a bit too much asking of DOS / Bash similarit= y.

It just seems to me quite challenging to write = Makefile in a portable way while --- sorry for repeating myself --- GNU Mak= e is missing those tasks called filterset=2C delete=2C mkdir=2C and copy in= ant.
GNU Make simply does not have these things built-in=2C this= is why most Makefile delegate them to Bash=2C and one can see find=2C rm= =2C mkdir and cp bash commands instead=2C which means that you get into tro= ubles when you want to use this Makefile on a plaform without Bash.
<= div>
Here we are talking on doing macro definition to have so= me portable tasks like =3B filterset=2C delete=2C mkdir=2C and copy in = ant --- i.e. not the same macro definition in DOS and in a unixy shell=2C b= ut that reasoning is quite unstatisfactory=2C because that means that every= time you are considering a new shell you will need to create again such a = set of macros --- or better=2C user defined function that one would $(call = ...).

So=2C you may argue that the real problem is= that Makefile call some bash commands=2C but I am more opinionated that th= e real problem is that GNU Make is missing the builtin features that would = allow one to do without those bash command in the statements in a standard = way=2C and without user defined macros/function to ensure portability.
 =3B

>=3B
>=3B >=3B Debugger entered--Lis= p error: (file-error "Opening output file" "no such file or directory" "d:/= devel/emacs/release/emacs24/emacs-24.1/lisp/c=3Bc:msys.0ProgrammeGNUinstall= ationcedet-installcedetlispcedetloaddefs.el")
>=3B = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=3B
>=3B See this non= sense? That's MSYS file syntax conversion in action.

<= div>[... SNIP ...]
>=3B =3B

Thank you aga= in for your commenting on it: I must admit that I was not aware that MSYS w= as so invasive in preprocessing arguments like that=2C I could not even ima= gine it=2C I had thought that emacs was the one doing those kind of argumen= t preprocessing.

That is all the more surprising t= hat the string that is transformed is within some simple-quotes.
=
>=3B >=3B What happens is that path `c:/Programme/GNU/installation= /cedet-install/cedet/lisp/cedet/loaddefs.el' in the command line transforme= d by EMACS into `c=3Bc:\msys\1.0\Programme\GNU\installation\cedet-install\= cedet\lisp\cedet\loaddefs.el'.
>=3B
>=3B Yes. This is what MSYS= does=2C and it does that for a good reason. The
>=3B problem is that= the algorithms MSYS applies for this conversion
>=3B misfire when the= program being invoked has its own ideas about the
>=3B syntax of the = command-line arguments. This is one such case.
>=3B (Invoking a nativ= ely-compiled Sed is another prominent case where the
>=3B MSYS file-na= me conversion badly misfires.)
>=3B

Ok= =2C I see=2C unless if you do the 's/find-this/replace-by-that/g' with some= other character than `/'=2C e.g. like that =3B's!find-this!replace-by-= that!g'  =3B

But your comment is quite interes= ting: would that mean that if emacs was compiled to be an MSYS application = then it would be able to prevent MSYS from doing mischiefs by telling to MS= YS which argument is supposed to be a path and which is not ?
I mean that EMACS people boasting that EMACS is ported on most = known platform seem not to consider MSYS as a platform on its own=2C i.e. i= t seems that EMACS Win32 port does not  =3Btest at all whether MSYSTEM = environment variable is set to MSYS or to MINGW32=2C nor whether OSTYPE is = set to msys ...

>=3B
>=3B >=3B Probably the reason = for doing that is quite valid: the path should have been ` c:\Programme\GNU= \installation\cedet-install\cedet\lisp\cedet\loaddefs.el' in the first plac= e.
>=3B
>=3B No. (Btw=2C using "D:/foo/bar" syntax of file name= s is perfectly OK on
>=3B Windows=2C because the Windows file I/O APIs= understand forward slashes
>=3B very well=2C but that's not the issue= here.) The problem is elsewhere:
>=3B this command-line argument is = _not_ a file name. It is a Lisp string
>=3B that will be interpreted = as a file name by Emacs. But MSYS does not
>=3B (and cannot) have the= slightest idea about valid syntax of Lisp
>=3B strings=3B in particul= ar=2C it doesn't know that a backslash in a Lisp
>=3B string needs to = be doubled. So it ruins the command line by its
>=3B simplistic conve= rsion.
>=3B =3B
>=3B >=3BMy thought are rather that = is it hard to write makefile that are portable because GNU Make is lacking = the following features:
>=3B >=3B
>=3B >=3B
>=3B >= =3B - a predefined variable=2C e.g. $(FS) expanding to the file separator= =2C i.e. \ for MSWindows and / for Unixy shell
>=3B
>=3B Why do = you need this? As I said=2C Windows programs=2C Emacs included=2C
>= =3B understand forward slashes in file names quite well. The only one
&= gt=3B that might have problems is cmd.exe=2C but you should not need to inv= oke
>=3B cmd.exe's commands too much=2C if at all.

Well=2C for instance=2C as far as I remember DEL is an MSDOS intern= al command=2C so at least for all the clean and such like targets --- which= quite common in any Makefile --- you need those backslash and not forward-= slash=2C if you assume that you have only MSDOS to rely on=2C and not MSYS = in your path=2C or at least RM variable defined to MSYS's rm.exe
=
>=3B And if you do need internal
>=3B cmd commands=2C= there are the 'subst' and 'patsubst' Make functions you
>=3B can use = to convert forward slashes to backslashes on the cmd command
>=3B line= s.
>=3B

But then that kind of mean using the= same sort of tricks to which I resorted to compile with MSYS. I was also d= oing those subst to have the backslashes in the first place and be sure tha= t no problem would happen become some SW (be it MSYS or EMACS) would do som= e mistake in badly converting forward slashed to backward slashes

>=3B Also=2C do you know that Make converts all environment variable= s to Make
>=3B variables=2C and expands them?
>=3B
>=3B >= =3B - a predefined variable=2C e.g. $(CFS)=2C expanding to the file separat= or within a C-string-like environment=2C i.e. \\ for MSWindows and / for Un= ixy shell
>=3B
>=3B Again=2C you should not need this at all. = This problem does not exist=2C
>=3B as long as you invoke Emacs from t= he Makefile.
>=3B
>=3B >=3B - a function=2C e.g. $(pathconvert= ...) to convert a path name in the the Unixy like format that make interna= lly uses with wildcards and $(abspath ...) returned value into the format u= sed on the platform where make is running=2C i.e. in my case `c:/Programme= /GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' would be conv= erted to `c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\loa= ddefs.el'
>=3B
>=3B Not needed=2C see above.
>=3B
>= =3B >=3B - and a function=2C e.g. $(cpathconvert ...) which would do the = same thing but with output to go within some C-string-like environement=2C = i.e. in my case
>=3B >=3B `c:/Programme/GNU/installation/cedet-inst= all/cedet/lisp/cedet/loaddefs.el' would be converted to `c:\\Programme\\G= NU\\installation\\cedet-install\\cedet\\lisp\\cedet\\loaddefs.el'
>=3B=
>=3B Again=2C not needed.
>=3B
>=3B >=3B Without those = basic things=2C one has no other resorts than the kind of tricks which I p= layed to make the Makefile platform independent=2C and which=2C I agree=2C = may be fragile=2C though working ones.
>=3B
>=3B You will have t= o explain why you at all need these basic things.
>=3B
>=3B >= =3B Please note that this is why I mentioned ant: in contrast to GNU Make= =2C ant has that sort of tricks that allow to do path name manipulations.>=3B
>=3B GNU Make has enough up its sleeve for this job=2C and m= any similar ones=2C
>=3B believe me.
>=3B

I would be more than quite happy to believe you=2C but it seems that I d= on't have enough expertize in GNU make for having this belief. And=2C this = lack of expertize --- of lack of things up the sleeve of GNU make=2C let us= see --- is not just mine: see it=2C CEDET's Makefile's are not portable to= DOS according to your criterion that the real problem is the use of Bash c= ommands. E.g. CEDET Makefile's call bash specific command `if [ -f .... ]= =3B then ... fi'. But surely CEDET people who created EDE know far more abo= ut writing Makefiles than I do. However CEDET's Makefile could be portable = to Win32 if you take it for granted that GNU Make cannot leave without some= Unixy shell nearby --- so MSYS under MSWindow ---=2C and therefore that th= e only remaining issue is path manipulation. Hence the FS=2C CFS=2C pathcon= vert and cpathconvert which I was suggesting.

VBR= =2C
 =3B  =3BVincent.

>=3B
>=3B
= --_da988ecf-14c7-4496-a3f8-ec2d56131a1a_--