emacs-devel
[Top][All Lists]

## 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: Tue, 02 Oct 2012 23:10:31 +0200

```> From: Vincent Belaïche <address@hidden>
> Date: Tue, 2 Oct 2012 22:31:03 +0200
>
> Looping also through Eli & emacs-devel.
>
>
>
> Please find attached the patch file cedet.diff to compile CEDET with make +
> MSYS --- this solves only the file path issue, but there is still some
> remaining problem.
>
>
> There is also one new file platform.mak to do some platform dependent
> settings. The whole trick which I propose is actually inside this
> platform.mak
>  file.
>
>
> I have not yet written any Changelog entry, I will do that when I get
> feedback on whether this correction is acceptable.
>
>
> The correction is that MSYS paths generated by MSYS make (like with \$(abspath
> ...) construct), are replaced by full fleshed MSWindows path.
>
>
> For instance file path
>  as MSYS views is, is replaced by
>
>
> Well, in fact for this one I have also to duplicate antislashes because it is
> passed via some lisp string.
>
>
> Since EMACS handles full-fleshed MSWindows path correctly, that is enough to
> solve the problem.
>
>
> The previous problem was that EMACS could not handle something like `/c' in
>  also using the notation
> which is what you can get with `pwd -W' is not sufficient, because it seems
> that EMACS does some preprocessing that changes this to
>  --- i.e. the `:' after c is handled kind of like a filename sepator --- this
> is almost good, but the spurious `c' was problematic. So I had to pipe the
> output of `pwd -W' into some sed one-liner.
>
>
> I had tried earlier some overload of expand-file-name passed to EMACS before
> the other arguments, but that did not allow me to go that far.
>
>
> Feedback / brickbats welcome.

I suggest not to use MSYS at all.  If the original CEDET Makefile's
cannot be changed to not require a Unixy shell, write a separate
Windows specific Makefile with equivalent commands, and be done with
that.  As a bonus, latest native ports of GNU Make support all the
functions that you needed to replace.  You can even replace Sed
commands with equivalent GNU Make functions, if you want.

MSYS is for configuring and building packages that use Autoconf and
other autotools.  It is not really appropriate for arbitrary Windows
jobs.  It can be done, of course, as your patch demonstrates, but it
will be fragile, and requires MSYS to be installed, which is a large
set of packages.

```

reply via email to