emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.


From: Eli Zaretskii
Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1
Date: Sun, 07 Oct 2012 09:06:46 +0200

> From: Vincent Belaïche <address@hidden>
> CC: "address@hidden"
>       <address@hidden>, "address@hidden"
>       <address@hidden>, emacs-devel <address@hidden>
> Date: Sat, 6 Oct 2012 23:41:21 +0200
> 
> Well, call this the "real problems" if you like, I am slightly sceptical on 
> what the real problem really is, most Makefiles I have seen in my life are 
> delegating some file manipulation tasks to some bash shell.

That's because most projects cannot assume GNU Make.  But for building
on MS-Windows with GNU tools, you _can_ assume that.

> Even the documentation of Make is most of the time doing this assumption --- 
> e.g. see those `rm ...' in the documentation of `clean' targets.

For the same reason: portability to other free platforms, like the
*BSD family, where the default Make is not GNU Make.

> The reason why so is that GNU make may have lots of thing in its sleeve, but, 
> AFAIK, it does not have builtins to do basical file manipation functions. So 
> it has to resort to some shell call, most of the time Bash. 

It does have quite a lot for manipulation of file _names_.  If you
mean functions for deleting and moving files, then no, it doesn't have
them.

> In contrast to GNU make, ant has the  filterset, delete, mkdir, and copy 
> tasks. So one does not need to delegate those basic things to any shell, and 
> build.xml files are made more portable this way.

If you are lobbying for switching to ant, I'm the wrong tree to bark
up ;-)

>  ------- end ------- As far as I can understand this failure happened when 
> this statement was met:
>     @$(foreach proj,$(PROJECTS_AUTOLOADS),cd $(CURDIR)/$(proj) && if [ -f 
> $(LOADDEFS) ];then $(RM) -f $(LOADDEFS);fi;)
> Quite surprising DOS does not bark on `cd  $(CURDIR)/$(proj)' despite the `/' 
> inside it

Like I said: quite a few of cmd's commands work with forward slashes,
especially if you put the file name in quotes.

> but the `if [ -f ... ]; ....; fi' instead of `IF EXIST ... ( ... )' was a bit 
> too much asking of DOS / Bash similarity.

The cmd syntax for the FOR loop and for the IF statement are
different.  You need to rewrite those; see the Emacs makefile.w32-in
files for how that is done in a way that works for both Unixy shell
and cmd.

Alternatively, you could use the Make foreach function.

> It just seems to me quite challenging to write Makefile in a portable way 
> while --- sorry for repeating myself --- GNU Make is missing those tasks 
> called filterset, delete, mkdir, and copy in ant.GNU Make simply does not 
> have these things built-in, this is why most Makefile delegate them to Bash, 
> and one can see find, rm, mkdir and cp bash commands instead, which means 
> that you get into troubles when you want to use this Makefile on a plaform 
> without Bash. 

Actually, it's not too hard.  Again, see the Emacs makefile.w32-in
files for how that is done.

> > See this nonsense?  That's MSYS file syntax conversion in action.
> [... SNIP ...]
> > 
> Thank you again for your commenting on it: I must admit that I was not aware 
> that MSYS was so invasive in preprocessing arguments like that, I could not 
> even imagine it, I had thought that emacs was the one doing those kind of 
> argument preprocessing.
> That is all the more surprising that the string that is transformed is within 
> some simple-quotes.

No, it's not simple at all.  The Lisp string syntax is complex (think
about escaping a quote; think about the significance of \NNN, etc.).
Without understanding all that, it is impossible to translate file
names inside Lisp strings without ruining them.  And Emacs is only one
program with one particular syntax.

> But your comment is quite interesting: 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 MSYS which argument is supposed to be a path 
> and which is not ?

Yes.  But no one has yet made Emacs able to build as an MSYS
application.

> 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, i.e. it seems that EMACS 
> Win32 port does not  test at all whether MSYSTEM environment variable is set 
> to MSYS or to MINGW32, nor whether OSTYPE is set to msys ...

To me, MSYS is not a platform.  It is a set of tools needed to
configure and build MinGW applications, when the build process uses
auto-tools.

> > > - a predefined variable, e.g. $(FS) expanding to the file separator, i.e. 
> > > \ for MSWindows and / for Unixy shell
> > 
> > Why do you need this?  As I said, Windows programs, Emacs included,
> > understand forward slashes in file names quite well.  The only one
> > that might have problems is cmd.exe, but you should not need to invoke
> > cmd.exe's commands too much, if at all.  
> Well, for instance, as far as I remember DEL is an MSDOS internal command, 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, if you 
> assume that you have only MSDOS to rely on, and not MSYS in your path, or at 
> least RM variable defined to MSYS's rm.exe

There's the GnuWin32 port of Coreutils, which has rm.exe, if you need
that.  Alternatively, use the GNU Make subst function to convert
forward slashes to backslashes on the DEL command line.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]