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>, emacs-devel <address@hidden>
> Date: Fri, 5 Oct 2012 07:18:53 +0200
> 
> 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/loaddefs.el, but 
> the same kind of path that pwd -W outputs, i.e. 
> c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el for 
> the same file. EMACS is supposed to understand that kind of path. However 
> that still does not work:

My crystal ball says that pwd is an MSYS program.  IOW, you still have
MSYS's /bin directory on your general PATH, and those MSYS tools,
especially Bash, are being invoked by the MinGW Make.

If you are invoking Make from the MSYS Bash console window, don't;
invoke it from a regular cmd window instead.  If you added MSYS's /bin
directory to your PATH such that even the cmd window gets that PATH,
edit your environment variables and remove the MSYS /bin directory
from the PATH.  Then these problems will go away, 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, but at
least you will be fighting known issues.

> Debugger entered--Lisp error: (file-error "Opening output file" "no such file 
> or directory" 
> "d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el")
                                                             
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

See this nonsense?  That's MSYS file syntax conversion in action.
Whenever an MSYS program (probably Bash in this case) invokes a native
Windows program (in this case Emacs), it converts any string that
looks like a Unixy file name with forward slashes and colons into a
Windows file name with backslashes and semi-colons.  But a single
backslash in a Lisp string is an escape character, so the file name is
butchered beyond repair by this conversion.

As long as you mix MSYS with native programs (with the exception of
MinGW compiler, linker, and other tools related to building software,
about which it is known in advance that their arguments are file
names), you will always see these problems, and you cannot possibly
work around them.  Again, MSYS was created for _building_ programs,
and it works very well in that domain.  But as soon as you leave the
domain of running the compiler and related tools, and start invoking
other native Windows programs, you are in trouble.

> What happens is that path  
> `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' in 
> the command line transformed by EMACS into  
> `c;c:\msys\1.0\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\loaddefs.el'.

Yes.  This is what MSYS does, 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.)

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

No.  (Btw, using "D:/foo/bar" syntax of file names is perfectly OK on
Windows, because the Windows file I/O APIs understand forward slashes
very well, 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; in particular, 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.

>My thought are rather that is it hard to write makefile that are portable 
>because GNU Make is lacking the following features:
> 
> 
> - 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.  And if you do need internal
cmd commands, there are the 'subst' and 'patsubst' Make functions you
can use to convert forward slashes to backslashes on the cmd command
lines.

Also, do you know that Make converts all environment variables to Make
variables, and expands them?

> - a predefined variable, e.g. $(CFS), expanding to the file separator within 
> a C-string-like environment, i.e. \\ for MSWindows and / for Unixy shell 

Again, you should not need this at all.  This problem does not exist,
as long as you invoke Emacs from the Makefile.

> - a function, e.g. $(pathconvert ...) to convert a path name in the the Unixy 
> like format that make internally uses with wildcards and $(abspath ...) 
> returned value into the format used on the platform where make is running, 
> i.e. in my case  
> `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' 
> would be converted to  
> `c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\loaddefs.el'

Not needed, see above.

> - and a function, e.g. $(cpathconvert ...) which would do the same thing but 
> with output to go within some C-string-like environement, i.e. in my case 
> `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' 
> would be converted to   
> `c:\\Programme\\GNU\\installation\\cedet-install\\cedet\\lisp\\cedet\\loaddefs.el'

Again, not needed.

> Without those basic things, one has no other resorts than the kind  of tricks 
> which I played to make the Makefile platform independent, and which, I agree, 
> may be fragile, though working ones.

You will have to explain why you at all need these basic things.

> Please note that this is why I mentioned ant: in contrast to GNU Make, ant 
> has that sort of tricks that allow to do path name manipulations.

GNU Make has enough up its sleeve for this job, and many similar ones,
believe me.