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

[Eli Zaretskii]

> From: Vincent Belaïche <address@hidden>
> CC: "address@hidden" <address@hidden>,
>       "address@hidden"
>       <address@hidden>, emacs-devel <address@hidden>
> Date: Sun, 7 Oct 2012 14:29:36 +0200
> 
> > > 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.

No, it's so that the Makefile one writes will be portable to those
other Make's.

> 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

Actually, Emacs doesn't have that problem at all, unless you call the
need to install rm and cp "a problem".

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

Unless the upstream maintainers are going to embrace those aspects
(which I suspect they won't), this is another nice idea steamrolled by
reality.

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

There's no practical way around that, in my experience.  Unless the
project in case only needs the shell and related utilities (in which
case using MSYS is fine out of the box).

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

Projects that use autoconf build very well with MSYS.  But Emacs isn't
one of them, because no one made its autoconf-produced scripts support
the MSYS/MinGW build.

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

It's not impossible, far from it.

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

If someone doesn't mind having another Emacs on their system, just to
byte-compile a bunch of files...

To me, it's easier to chdir into a directory and say something like

  emacs -batch -f batch-byte-compile *.el

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

They are unreliable as Windows apps.  You've just seen a very good
example.