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

[Vincent Belaïche]

Hello,


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:



Here is the beginning of the mingw32-make output


-----------------------------------------------------------------------
Emacs version: 24.1.1 nil on windows-nt
Removing loaddefs.el files from subprojects.
Generating autoloads.
mingw32-make[1]: Entering directory `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet'
'c:/Programme/GNU/emacs-24.1/bin/emacs.exe' -batch --no-site-file --eval '(setq debug-on-error t)' -l "../../cedet-remove-builtin.el" -L ../eieio/ -L ./ -L ./ --eval '(setq generated-autoload-file "c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el")' -f batch-update-autoloads 'c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet'
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")
write-region(";;; c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el --- automatically extracted autoloads\n;;\n;;; Code:\n\n\f\n(provide 'c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs)\n;; Local Variables:\n;; version-control: never\n;; no-byte-compile: t\n;; no-update-autoloads: t\n;; coding: utf-8\n;; End:\n;;; c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el ends here\n" nil "d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el")
autoload-ensure-default-file("d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el")
autoload-find-generated-file()
update-directory-autoloads("c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet")
apply(update-directory-autoloads "c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet")
batch-update-autoloads()
command-line-1(("--eval" "(setq debug-on-error t)" "-l" "../../cedet-remove-builtin.el" "-L" "../eieio/" "-L" "./" "-L" "./" "--eval" "(setq generated-autoload-file \"c;c:\\msys\\1.0\\Programme\\GNU\\installation\\cedet-install\\cedet\\lisp\\cedet\\loaddefs.el\")" "-f" "batch-update-autoloads" "c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet"))
command-line()
normal-top-level()

mingw32-make[1]: *** [autoloads] Error -1
mingw32-make[1]: Leaving directory `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet'

-----------------------------------------------------------------------


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


So I would not conclude that EMACS is the one to blame, EMACS is just trying to survive in the adverse MSWindows environment by doing some tricks, which besides shows that EMACS has some awareness that MSYS is installed on the machine (probably through the MSYS environment variable that is defined to `c:\msys\1.0\'. 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
- 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 
- 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'
- 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'


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.


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.


VBR,
   Vincent.