RE: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1

[Vincent Belaïche]

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

Note: in the next feedback you write that GNU Make does not have any builtin delete, and here refering to `rm ...' you write that this is for compatibility with BSD where GNU Make is not the default make. It seems, that the real reason is not for BSD compatibility but just that there isn't a builtin delete

Well, I presume that adding those delete/copy/... builtin's into GNU Make would make it even less compatible with existing other make implementations. On the other hand GNU make is open source and can be ported on most platform, so would that really be a problem to have additional builtin's.

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

I was meaning the latter, deleting/moving/copying files, or even some basic file content translation. All of which ant is capable.

> > 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 ;-)

Well, that is not my real motivation, I don't care whether the solution is switching to ant or improving the way that makefiles are written. 

What I am seeking is that building GNU projects and other open source Linux centric project be a little easier on MSWindows. It is already inherently more complex because you have to install some build system that is not de facto on MSWindows, but on top of that building scripts are not portable --- or said otherwise there are different building scripts for Unixy and MSWindows. Which means that MSWindows scripts are often out-of-date.

EMACS is not the only package that has this problem, I remember that once upon a time I tried to compile Hevea using MSYS and that also proved out impossible. The standard way to do it was to use a batch file that was generated by SomeoneTM runnning the Linux makefile, and then post-processing the log to generate some batch file that launch all the command --- i.e. you do a re-build all and loose the good property of make that builds only what is needed.

Well, in a nutshell, improving that aspects of GNU Make would benefit many projects relying on it, not only CEDET.

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

Yes, but don't you think that maintaining two different makefiles one for MSWindows and one for Linux is duplicating maintenance work. Of course one cannot escape that some sub-module of of the application would remain platform specific and as such would have some different makefile depending on which the platform is. However for the bulk of the application exactly the same makefile should be possible to use if GNU make had more multi-platform scripting capability --- meaning that exactly the same Make script can do anywhere without resorting to platform specific MACRO / user defined functions.

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

I fully agree it is not too hard, but it just has to be done. Multiply this by all the projects using make, and it becomes hard if you think it as a global effort rather than an individual effort. After all the whole thing about free software is sharing resource so that anyone can start a big thing with an affordable effort, as he/she can reuse other's work.

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

Is that that nobody has tried it by lack of motivation --- that would be a very good reason indeed --- or was it impossible for some technical reason ? Look: emacs is used as a byte-compiler, so just like other gcc, ar, etc.. compile tool, porting EMACS to become an MSYS application would make any EMACS package compilation makefile using command line byte-compile de-facto portable under MSYS.

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

Well, that is correct. Nevertheless MSYS applications like pwd, rm, tar, gzip, etc... are not plain MSWindows native application, they have some trick to work both as native MSWindows application and as MSYS applications.

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

The second alternative seems better to me.

VBR, and many thanks for the feedback,

   Vincent.