Re: Latest CEDET on BZR does not compile with emacs 24.1

Re: Latest CEDET on BZR does not compile with emacs 24.1

[Vincent Belaïche]

[-- Attachment #1.1: Type: text/plain, Size: 2600 bytes --]


Hello David et alii,


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 `/c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el', as MSYS views is, is replaced by c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\ede\loaddefs.el.


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  `/c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el', also using the notation   c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el which is what you can get with `pwd -W' is not sufficient, because it seems that EMACS does some preprocessing that changes this to  c;c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\ede\loaddefs.el --- 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.


VBR,
   Vincent.

> From: deng@randomsample.de
> To: vincent.b.1@hotmail.fr
> CC: cedet-semantic@lists.sourceforge.net
> Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1
> Date: Mon, 1 Oct 2012 17:21:51 +0200
> 
> Vincent Belaïche writes:
> > Thanks for the feedback, I will see if I can make some hack to overload
> > expand-file-name so that MSYS paths are interpreted correctly, and let you
> > know.
> 
> Good luck, but may I suggest again that you just ask on emacs-help?
> People like Eli read there who happen to know this MSYS business inside
> out.
> 
> -David
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 3035 bytes --]

[-- Attachment #2: platform.mak --]
[-- Type: application/octet-stream, Size: 1073 bytes --]

# Platform dependent settings
#
# (C) 2011, 2012 CEDET Developers
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Emacs; see the file COPYING.  If not, write to the
# Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
ifeq ($(OSTYPE) , msys)
	AP_LOADDEFS = $(shell cd $(dir $(abspath $(LOADDEFS))); echo $$(pwd -W)"/$(notdir $(LOADDEFS))" | sed 's!/!\\\\!g')
	AP_LOADDIRS = $(shell cd $(LOADDIRS); pwd -W | sed 's!/!\\!g')
else
	AP_LOADDEFS = $(abspath $(LOADDEFS))
	AP_LOADDIRS = $(abspath $(LOADDIRS))
endif


[-- Attachment #3: cedet.diff --]
[-- Type: application/octet-stream, Size: 5343 bytes --]

=== modified file 'lisp/cedet/cogre/Makefile'
--- lisp/cedet/cogre/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/cedet/cogre/Makefile	2012-10-02 18:53:38 +0000
@@ -23,6 +23,7 @@
 cogre_LISP=uml.el periodic.el ascii.el srecode.el convert.el layout.el semantic.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/cedet/cogre
+include ../../../platform.mak
 
 
 
@@ -34,7 +35,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %-wy.el: %.wy

=== modified file 'lisp/cedet/ede/Makefile'
--- lisp/cedet/ede/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/cedet/ede/Makefile	2012-10-02 18:53:38 +0000
@@ -21,6 +21,7 @@
 aux-lisp_LISP=autoconf-edit.el makefile-edit.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/cedet/ede
+include ../../../platform.mak
 
 
 
@@ -32,7 +33,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %.elc: %.el

=== modified file 'lisp/cedet/Makefile'
--- lisp/cedet/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/cedet/Makefile	2012-10-02 18:54:06 +0000
@@ -19,7 +19,7 @@
 init_LISP=semantic.el srecode.el ede.el cogre.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/cedet
-
+include ../../platform.mak
 
 
 all: common init srecode semantic EDE Cogre
@@ -30,7 +30,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file  "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %.elc: %.el

=== modified file 'lisp/cedet/semantic/Makefile'
--- lisp/cedet/semantic/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/cedet/semantic/Makefile	2012-10-02 18:53:40 +0000
@@ -26,6 +26,7 @@
 metagrammar_SEMANTIC_GRAMMAR_EL=grammar-wy.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/cedet/semantic
+include ../../../platform.mak
 
 
 
@@ -37,7 +38,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %.elc: %.el

=== modified file 'lisp/cedet/srecode/Makefile'
--- lisp/cedet/srecode/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/cedet/srecode/Makefile	2012-10-02 18:55:22 +0000
@@ -20,6 +20,7 @@
 srecode_LISP=mode.el compile.el insert.el semantic.el template.el dictionary.el args.el table.el filters.el find.el ctxt.el getset.el cpp.el expandproto.el el.el srt.el texi.el map.el extract.el java.el fields.el android.el document.el m3.el srt-mode.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/cedet/srecode
+include ../../../platform.mak
 
 
 
@@ -31,7 +32,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %-wy.el: %.wy

=== modified file 'lisp/eieio/Makefile'
--- lisp/eieio/Makefile	2012-04-21 11:39:55 +0000
+++ lisp/eieio/Makefile	2012-10-02 18:53:41 +0000
@@ -19,6 +19,7 @@
 examples_LISP=chart.el eieio-speedbar.el linemark.el eieio-xml.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/eieio
+include ../../platform.mak
 
 
 
@@ -30,7 +31,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %.elc: %.el

=== modified file 'lisp/speedbar/Makefile'
--- lisp/speedbar/Makefile	2012-09-13 19:17:45 +0000
+++ lisp/speedbar/Makefile	2012-10-02 18:53:41 +0000
@@ -18,8 +18,7 @@
 opt_LISP=rpm.el sb-info.el sb-rmail.el sb-texinfo.el sb-html.el sb-ant.el
 VERSION=1.1beta
 DISTDIR=$(top)cedet-topdir-$(VERSION)/speedbar
-
-
+include ../../platform.mak
 
 all: opt
 
@@ -29,7 +28,7 @@
 
 .PHONY: autoloads
 autoloads: 
-	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(abspath $(LOADDEFS))")' -f batch-update-autoloads $(abspath $(LOADDIRS))
+	$(EMACS) $(EMACSFLAGS) $(addprefix -L ,$(LOADPATH)) --eval '(setq generated-autoload-file "$(AP_LOADDEFS)")' -f batch-update-autoloads '$(AP_LOADDIRS)'
 
 
 %.elc: %.el


[-- Attachment #4: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

[-- Attachment #5: Type: text/plain, Size: 173 bytes --]

_______________________________________________
cedet-semantic mailing list
cedet-semantic@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-semantic

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>
> 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 `/c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el', as MSYS views is, is replaced by c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\ede\loaddefs.el.
> 
> 
> 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  `/c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el', also using the notation   c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/ede/loaddefs.el which is what you can get with `pwd -W' is not sufficient, because it seems that EMACS does some preprocessing that changes this to  c;c:\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\ede\loaddefs.el --- 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.

Re: Latest CEDET on BZR does not compile with emacs 24.1

[David Engster]

Vincent Belaïche writes:
> 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.

Here's the thing: our Makefiles are generated by EDE (except the
top-level one). Hence it doesn't make sense to patch them. We only have
them under version control because generating them on the fly would be
slow and have very little benefit.

I could add your patch to EDE's Makefile generation itself, but frankly,
I do not see the point. As Eli says, these kinds of patches for bending
things to work with MSYS tend to be fragile. And as you've already
experienced, this is not the only issue; I actually tried using MSYS for
our Windows Buildbot slave about a year ago and just gave up after
hitting numerous problems.

As I've already written on semantic-devel, we have a way of building
CEDET without using Makefiles at all (using cedet-build.el); while it is
currently broken after all the changes we introduced lately, it should
be easy to fix. I probably have time for it this week.

And finally, there's always Cygwin. :-)

-David

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Re: Latest CEDET on BZR does not compile with emacs 24.1

[Vincent Belaïche]

[-- Attachment #1.1: Type: text/plain, Size: 3147 bytes --]




> Date: Tue, 2 Oct 2012 23:10:31 +0200
> From: eliz@gnu.org
> Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs	24.1
> To: vincent.b.1@hotmail.fr
> CC: cedet-semantic@lists.sourceforge.net; deng@randomsample.de; emacs-devel@gnu.org
> 
> > From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> > CC: "cedet-semantic@lists.sourceforge.net"
> > 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>

[... SNIP ...]> 
> I suggest not to use MSYS at all.  
Is that a general recommendation --- i.e. do not build EMACS with MSYS --- or is that a recommendation for CEDET only. It happens that I could not compile EMACS with MSYS for some time --- is the MSYS port abandoned ?
> If the original CEDET Makefile's
> cannot be changed to not require a Unixy shell, 
The only MSWindows port of GNUMake which I know is the MSYS one. Cygwin is not really a Windows port, it is rather some Unixy environment emulation under MSWindows.
I tried the Makefile with dmake and here is what it does:
C:\Programme\GNU\installation\cedet-install\cedet>dmake EMACS=c:\Programme\GNU\emacs-24.1\bin\emacs.exe 
dmake EMACS=c:\Programme\GNU\emacs-24.1\bin\emacs.exe 
dmake.exe:  makefile:  line 46:  Error: -- Missing targets or attributes in rule

i.e. it seems that dmake is less advanced than GNU Make and does not support addsufix function. 
> write a separate
> Windows specific Makefile with equivalent commands, and be done with
> that.  
I am afraid that the trick which I did is tremendously simpler to do and to maintain than what I understood that you are suggesting. I am not going to re-write all the CEDET Makefiles just to use an MSWindows make engine. I've  read from David that those Makefiles are generated by EDE, so if ever there was something to do, it would be better to upgrade EDE to generates those MSWindows makefile, or anything working well under MSWindows without the need for a Unixy shell (e.g. ant build.xml files). Anyhow, CEDET can be built with some lisp only script that will be soon fixed, so even this thing is not needed.
> 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.
>
Thank you for the advice, I totally agree with this one, Makefile internal text & path manipulation should be done as much as possible platform independent.I attached a corrected `platform.mak' which does not use sed but only GNU make functions. You are right, sed is a little old fashioned and not always available.
> 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.
> 
Well, I have already MSYS installed, so I did not need any extra installation, while using Cygwin was the opposite in my case, that would have meant installing a large package.
Kind regards,   Vincent. 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 3910 bytes --]

[-- Attachment #2: platform.mak --]
[-- Type: application/octet-stream, Size: 1065 bytes --]

# Platform dependent settings
#
# (C) 2011, 2012 CEDET Developers
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Emacs; see the file COPYING.  If not, write to the
# Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
ifeq ($(OSTYPE) , msys)
	AP_LOADDEFS = $(subst /,\\,$(shell cd $(dir $(abspath $(LOADDEFS))); echo "$$(pwd -W)/$(notdir $(LOADDEFS))" ))
	AP_LOADDIRS = $(subst /,\,$(shell cd $(LOADDIRS); pwd -W))
else
	AP_LOADDEFS = $(abspath $(LOADDEFS))
	AP_LOADDIRS = $(abspath $(LOADDIRS))
endif


[-- Attachment #3: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

[-- Attachment #4: Type: text/plain, Size: 173 bytes --]

_______________________________________________
cedet-semantic mailing list
cedet-semantic@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Re: Latest CEDET on BZR does not compile with emacs 24.1

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, "deng@randomsample.de"
> 	<deng@randomsample.de>, emacs-devel <emacs-devel@gnu.org>
> Date: Wed, 3 Oct 2012 22:02:37 +0200
> 
> > I suggest not to use MSYS at all.  
> Is that a general recommendation --- i.e. do not build EMACS with MSYS --- or is that a recommendation for CEDET only.

For Emacs in general.  And in fact, for any job that needs Make and
GCC, but does not need running Unixy shells, be it the configure
script or shell snippets inside Makefile's.

>It happens that I could not compile EMACS with MSYS for some time --- is the MSYS port abandoned ?

As you can see in nt/INSTALL, using the MSYS shell is not supported by
the Windows Makefile's used to build Emacs.  I occasionally hear
reports that someone succeeded to build using MSYS anyway, so I guess
with enough tweaking it can work.  But it isn't supported.

If the Windows build procedure will ever switch to running the Unix
configure script and the Unix Makefile's, then MSYS will of course be
the recommended way of building Emacs.  But for that, Someone™ will
have to adapt both the configury and the Makefile.in files to the
special needs of the Windows build, such as compiling Windows-only
source files and programs, etc.

> > If the original CEDET Makefile's
> > cannot be changed to not require a Unixy shell, 
> The only MSWindows port of GNUMake which I know is the MSYS one. Cygwin is not really a Windows port, it is rather some Unixy environment emulation under MSWindows.

There's a MinGW port available here:

  http://sourceforge.net/projects/mingw/files/MinGW/Extension/make/

(The latest CVS snapshot even supports the job server in parallel
builds, so you can put multi-core machines to good use.)  And you can
easily compile the MinGW port of Make yourself from sources, by
running a single batch file that comes with the sources, you just need
a working compiler installation.

> I tried the Makefile with dmake and here is what it does:

Well, I surely didn't mean to advise you to use dmake ;-)

> > write a separate
> > Windows specific Makefile with equivalent commands, and be done with
> > that.  
> I am afraid that the trick which I did is tremendously simpler to do and to maintain than what I understood that you are suggesting. I am not going to re-write all the CEDET Makefiles just to use an MSWindows make engine.

From what I saw, it's not very hard, if at all needed.  Just try the
MinGW Make and see where it fails, if at all.

>I've  read from David that those Makefiles are generated by EDE, so if ever there was something to do, it would be better to upgrade EDE to generates those MSWindows makefile, or anything working well under MSWindows without the need for a Unixy shell (e.g. ant build.xml files). Anyhow, CEDET can be built with some lisp only script that will be soon fixed, so even this thing is not needed.

That is probably the best option.


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
cedet-semantic mailing list
cedet-semantic@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Re: Latest CEDET on BZR does not compile with emacs 24.1

[Vincent Belaïche]

[-- Attachment #1.1: Type: text/plain, Size: 5284 bytes --]


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. 

 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 5663 bytes --]

[-- Attachment #2: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

[-- Attachment #3: Type: text/plain, Size: 173 bytes --]

_______________________________________________
cedet-semantic mailing list
cedet-semantic@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-semantic

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>
> 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.

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

[David Engster]

Vincent Belaïche writes:
> I am not going to re-write all the CEDET Makefiles just to use an
> MSWindows make engine. I've read from David that those Makefiles are
> generated by EDE, so if ever there was something to do, it would be
> better to upgrade EDE to generates those MSWindows makefile, or
> anything working well under MSWindows without the need for a Unixy
> shell (e.g. ant build.xml files).

Yes, that would be the way to go. You can generate pretty much any kind
of build script using EDE. In fact, if you look into our Elisp build
script cedet-build.el, you'll see that it also calls EDE to build the
targets without using Make. (It calls `project-compile-target' on the
target, which is an object; those methods are defined in
ede/proj-elisp.el and in semantic/ede-grammar.el for the
byte-compilation and parser generation, resp.).

> Anyhow, CEDET can be built with some lisp only script that will be
> soon fixed, so even this thing is not needed.

I think I fixed it now. Please check out latest CEDET from bzr and try

emacs -Q -l cedet-build.el -f cedet-build

Please let me know if you see any errors.

-David

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 12892 bytes --]


Hello,


It seems that it works perfect. Here is what I got from the command line in another emacs frame:

----------------------------- begin -------------------------
CEDET BYTE COMPILATION STATUS:

Step 1: Byte compile EIEIO...done
Step 2: Creating autoloads ...
Step 2.1: EIEIO Autoloads...done.
Step 2.2: CEDET Autoloads...done.
Step 2.3: EDE Autoloads...done.
Step 2.4: Semantic Autoloads...done.
Step 2.5: SRecode Autoloads...done.
Step 2.6: COGRE Autoloads...done.
Step 2.7: Speedbar Autoloads...done.
Step 3: initialize CEDET from external repository ...done
Step 4: Turning on EDE and Semantic ...done.

Step 5: Build Targets in: ("lisp")

Build Emacs Lisp Targets:
-------------------------
Building directory lisp
  Project: cedet-topdir
  Project: speedbar
   Target opt...                 0 compiled, 6 up to date.
  Project: eieio
   Target eieio...               1 compiled, 5 up to date.
   Target examples...            0 compiled, 4 up to date.
  Project: cedet
   Target common...              2 compiled, 16 up to date.
   Target subproj-top...         2 compiled, 2 up to date.
  Project: cedet/srecode
   Target lang...                0 compiled, 1 up to date.
   Target srecode...             1 compiled, 24 up to date.
  Project: semantic
   Target semantic...            1 compiled, 13 up to date.
   Target utils...               0 compiled, 5 up to date.
   Target Database...            0 compiled, 16 up to date.
   Target tools...               0 compiled, 16 up to date.
   Target subprojects-top...     0 compiled, 5 up to date.
   Target Languages...           0 compiled, 3 up to date.
   Target maintenance...         1 compiled, 0 up to date.
   Target metagrammar...         1 compiled, 0 up to date.
  Project: semantic/wisent
   Target wy...                  1 compiled, 4 up to date.
   Target tools...               0 compiled, 1 up to date.
   Target wisent...              0 compiled, 6 up to date.
   Target languages...           1 compiled, 4 up to date.
  Project: semantic/symref
   Target symref...              0 compiled, 6 up to date.
  Project: semantic/ectags
   Target ectags...              0 compiled, 5 up to date.
  Project: semantic/decorate
   Target decorate...            0 compiled, 2 up to date.
  Project: semantic/bovine
   Target by...                  5 compiled, 0 up to date.
   Target bovinator...           0 compiled, 3 up to date.
   Target languages...           0 compiled, 8 up to date.
  Project: semantic/analyze
   Target analyze...             0 compiled, 4 up to date.
  Project: EDE
   Target ede...                 1 compiled, 15 up to date.
   Target proj-project...        1 compiled, 12 up to date.
   Target projects...            1 compiled, 5 up to date.
   Target aux-lisp...            1 compiled, 1 up to date.
  Project: cedet/cogre
   Target wy...                  0 compiled, 1 up to date.
   Target dot...                 0 compiled, 2 up to date.
   Target Mode...                0 compiled, 1 up to date.
   Target hacks...               0 compiled, 1 up to date.
   Target cogre...               0 compiled, 7 up to date.


Done.

 ----------------------------- end ------------------------- 


Then I did some make clean-all, and then I tried M-x cedet-build-in-this-emacs, and then I got this:



 ----------------------------- begin ------------------------- 

CEDET BYTE COMPILATION STATUS:

Step 1: Byte compile EIEIO...
 ----------------------------- end ------------------------- 
and then it kind of got frozen. In the *Message* buffer there was:


progn: You should not recompile EIEIO after it has been loaded, which 



Then I tried again from the command line --- but within some EMACS MSYS bash buffer, with putting -batch in the command line and I got:



 ----------------------------- begin ------------------------- 

/c/Programme/GNU/installation/cedet-install/cedet>emacs -batch -l cedet-build.el -f cedet-build

Wrote c:/Programme/GNU/installation/cedet-install/cedet/lisp/eieio/eieio.elc

Loading c:/Programme/GNU/installation/cedet-install/cedet/cedet-devel-load.el (source)...
Loading c:/Programme/GNU/installation/cedet-install/cedet/cedet-remove-builtin.el (source)...
Loading autoloads from CEDET development.

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp opt>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp eieio>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp examples>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp common>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp subproj-top>

Loading semantic/db-file...
Loading vc-bzr...
Package `srecode-template-wy' is up to date.
All Semantic Grammar sources are up to date in #<semantic-ede-proj-target-grammar lang>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp srecode>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp semantic>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp utils>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp Database>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp tools>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp subprojects-top>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp Languages>

All Emacs Lisp sources are up to date in #<ede-proj-target-elisp maintenance>

Package `semantic-grammar-wy' is up to date.
All Semantic Grammar sources are up to date in #<semantic-ede-proj-target-grammar metagrammar>

Saving file c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/semantic/wisent/java-tags-wy.el...
Wrote c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/semantic/wisent/java-tags-wy.el
CEDET BYTE COMPILATION STATUS:

Step 1: Byte compile EIEIO...done
Step 2: Creating autoloads ...
Step 2.1: EIEIO Autoloads...done.
Step 2.2: CEDET Autoloads...done.
Step 2.3: EDE Autoloads...done.
Step 2.4: Semantic Autoloads...done.
Step 2.5: SRecode Autoloads...done.
Step 2.6: COGRE Autoloads...done.
Step 2.7: Speedbar Autoloads...done.
Step 3: initialize CEDET from external repository ...done
Step 4: Turning on EDE and Semantic ...done.

Step 5: Build Targets in: ("lisp")

Build Emacs Lisp Targets:
-------------------------
Building directory lisp
  Project: cedet-topdir
  Project: speedbar
   Target opt...                 0 compiled, 6 up to date.
  Project: eieio
   Target eieio...               0 compiled, 6 up to date.
   Target examples...            0 compiled, 4 up to date.
  Project: cedet
   Target common...              0 compiled, 18 up to date.
   Target subproj-top...         0 compiled, 4 up to date.
  Project: cedet/srecode
   Target lang...                0 compiled, 1 up to date.
   Target srecode...             0 compiled, 25 up to date.
  Project: semantic
   Target semantic...            0 compiled, 14 up to date.
   Target utils...               0 compiled, 5 up to date.
   Target Database...            0 compiled, 16 up to date.
   Target tools...               0 compiled, 16 up to date.
   Target subprojects-top...     0 compiled, 5 up to date.
   Target Languages...           0 compiled, 3 up to date.
   Target maintenance...         0 compiled, 1 up to date.
   Target metagrammar...         0 compiled, 1 up to date.
  Project: semantic/wisent
   Target wy...                  Create directory d:/msys/1.0/home/Vincent/.emacs.d/semanticdb/ for SemanticDB? (y or n) y
No buffer named java-tags-wy.el
Saving file d:/msys/1.0/home/Vincent/.emacs.d/ede-projects.el...
Wrote d:/msys/1.0/home/Vincent/.emacs.d/ede-projects.el
/c/Programme/GNU/installation/cedet-install/cedet>

 ----------------------------- end ------------------------- 



Then I did make clean-all again, and I tried again  emacs -Q -l cedet-build.el -f cedet-build and I got: 



  ----------------------------- begin ------------------------- 
 
CEDET BYTE COMPILATION STATUS:

Step 1: Byte compile EIEIO...done
Step 2: Creating autoloads ...
Step 2.1: EIEIO Autoloads...done.
Step 2.2: CEDET Autoloads...done.
Step 2.3: EDE Autoloads...done.
Step 2.4: Semantic Autoloads...done.
Step 2.5: SRecode Autoloads...done.
Step 2.6: COGRE Autoloads...done.
Step 2.7: Speedbar Autoloads...done.
Step 3: initialize CEDET from external repository ...done
Step 4: Turning on EDE and Semantic ...done.

Step 5: Build Targets in: ("lisp")

Build Emacs Lisp Targets:
-------------------------
Building directory lisp
  Project: cedet-topdir
  Project: speedbar
   Target opt...                 0 compiled, 6 up to date.
  Project: eieio
   Target eieio...               0 compiled, 6 up to date.
   Target examples...            0 compiled, 4 up to date.
  Project: cedet
   Target common...              0 compiled, 18 up to date.
   Target subproj-top...         0 compiled, 4 up to date.
  Project: cedet/srecode
   Target lang...                0 compiled, 1 up to date.
   Target srecode...             0 compiled, 25 up to date.
  Project: semantic
   Target semantic...            0 compiled, 14 up to date.
   Target utils...               0 compiled, 5 up to date.
   Target Database...            0 compiled, 16 up to date.
   Target tools...               0 compiled, 16 up to date.
   Target subprojects-top...     0 compiled, 5 up to date.
   Target Languages...           0 compiled, 3 up to date.
   Target maintenance...         0 compiled, 1 up to date.
   Target metagrammar...         0 compiled, 1 up to date.
  Project: semantic/wisent
   Target wy...                  5 compiled, 0 up to date.
   Target tools...               1 compiled, 0 up to date.
   Target wisent...              6 compiled, 0 up to date.
   Target languages...           5 compiled, 0 up to date.
  Project: semantic/symref
   Target symref...              6 compiled, 0 up to date.
  Project: semantic/ectags
   Target ectags...              5 compiled, 0 up to date.
  Project: semantic/decorate
   Target decorate...            2 compiled, 0 up to date.
  Project: semantic/bovine
   Target by...                  5 compiled, 0 up to date.
   Target bovinator...           3 compiled, 0 up to date.
   Target languages...           8 compiled, 0 up to date.
  Project: semantic/analyze
   Target analyze...             4 compiled, 0 up to date.
  Project: EDE
   Target ede...                 0 compiled, 16 up to date.
   Target proj-project...        0 compiled, 13 up to date.
   Target projects...            0 compiled, 6 up to date.
   Target aux-lisp...            0 compiled, 2 up to date.
  Project: cedet/cogre
   Target wy...                  0 compiled, 1 up to date.
   Target dot...                 0 compiled, 2 up to date.
   Target Mode...                0 compiled, 1 up to date.
   Target hacks...               0 compiled, 1 up to date.
   Target cogre...               0 compiled, 7 up to date.


Done.

 ----------------------------- end ------------------------- 



BTW, I still have the problem with 


Package lmenu is obsolete!
Package sregex is obsolete!



Are these packages from standard emacs ?


VBR,
   Vincent

> From: deng@randomsample.de
> To: vincent.b.1@hotmail.fr
> CC: eliz@gnu.org; cedet-semantic@lists.sourceforge.net; emacs-devel@gnu.org
> Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1
> Date: Sat, 6 Oct 2012 12:25:30 +0200
> 
> Vincent Belaïche writes:
> > I am not going to re-write all the CEDET Makefiles just to use an
> > MSWindows make engine. I've read from David that those Makefiles are
> > generated by EDE, so if ever there was something to do, it would be
> > better to upgrade EDE to generates those MSWindows makefile, or
> > anything working well under MSWindows without the need for a Unixy
> > shell (e.g. ant build.xml files).
> 
> Yes, that would be the way to go. You can generate pretty much any kind
> of build script using EDE. In fact, if you look into our Elisp build
> script cedet-build.el, you'll see that it also calls EDE to build the
> targets without using Make. (It calls `project-compile-target' on the
> target, which is an object; those methods are defined in
> ede/proj-elisp.el and in semantic/ede-grammar.el for the
> byte-compilation and parser generation, resp.).
> 
> > Anyhow, CEDET can be built with some lisp only script that will be
> > soon fixed, so even this thing is not needed.
> 
> I think I fixed it now. Please check out latest CEDET from bzr and try
> 
> emacs -Q -l cedet-build.el -f cedet-build
> 
> Please let me know if you see any errors.
> 
> -David
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 14095 bytes --]

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

[David Engster]

Vincent Belaïche writes:
> Target Database... 0 compiled, 16 up to date.

Well, it seems almost everything seems to be already compiled from your
previous efforts.

> Then I did some make clean-all, and then I tried M-x cedet-build-in-this-emacs,
> and then I got this:

No, that's not working (yet). Please only do

emacs -Q -l cedet-build.el -f cedet-build

on a CEDET clean checkout. Everything else is not tested and will
probably not work.

> /c/Programme/GNU/installation/cedet-install/cedet>emacs -batch -l
> cedet-build.el -f cedet-build

Not the right command. Do not use '-batch', but use '-Q'.

> BTW, I still have the problem with 
>
> Package lmenu is obsolete!
> Package sregex is obsolete!
> Are these packages from standard emacs ?

No. But CEDET does not use these packages. They're probably loaded from
your init- or site-file.

-David

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]


[... SNIP ...]

> > BTW, I still have the problem with 
> >
> > Package lmenu is obsolete!
> > Package sregex is obsolete!
> > Are these packages from standard emacs ?
> 
> No. But CEDET does not use these packages. They're probably loaded from
> your init- or site-file.
> 
> -David
> 



Thank you for the feedback, that is probably loaded by JDEE, as I already wrote to you I needed an up-to-date CEDET to use JDEE.


VBR,
   Vincent.


PS: resending as I did Reply instead of Reply-all the first time.

 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 865 bytes --]

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 12137 bytes --]


Feedback inserted below:

> Date: Fri, 5 Oct 2012 10:10:38 +0200
> From: eliz@gnu.org
> Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs	24.1
> To: vincent.b.1@hotmail.fr
> CC: cedet-semantic@lists.sourceforge.net; deng@randomsample.de; emacs-devel@gnu.org
> 
> > From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> > CC: "cedet-semantic@lists.sourceforge.net"
> > 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>
> > 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, 
Your crystal ball is perfectly correct
> 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.  
I tried both actually, but, true, MSYS's /bin was in the PATH in both cases
> 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.
Well, call this the "real problems" if you like, I am slightly sceptical on what the real problem really is, most Makefiles I have seen in my life are delegating some file manipulation tasks to some bash shell. Even the documentation of Make is most of the time doing this assumption --- e.g. see those `rm ...' in the documentation of `clean' targets.
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. 
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.
Considering CEDET I tried what you said, I wrote an MSDOS batch file with this content (the first line ensures that I have both mingw32-make and emacs in the PATH, but no more :
------- begin -------SET PATH=c:\msys\1.0\mingw\bin;c:\Programme\GNU\emacs-24.1\bin
SET RM=DEL

CD cedet
mingw32-make

CD ..
 ------- end ------- 
and that failed quite soon with this output:
------- begin -------

C:\Programme\GNU\installation\cedet-install>SET PATH=c:\msys\1.0\mingw\bin;c:\Programme\GNU\emacs-24.1\bin 

C:\Programme\GNU\installation\cedet-install>SET RM=DEL 

C:\Programme\GNU\installation\cedet-install>CD cedet 

C:\Programme\GNU\installation\cedet-install\cedet>mingw32-make
Emacs version: 24.1.1 nil on windows-nt 
Removing loaddefs.el files from subprojects.
-f était inattendu.
mingw32-make: *** [clean-autoloads] Error 255

C:\Programme\GNU\installation\cedet-install\cedet>CD .. 
 ------- 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, but the `if [ -f ... ]; ....; fi' instead of `IF EXIST ... ( ... )' was a bit too much asking of DOS / Bash similarity.
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. 
Here we are talking on doing macro definition to have some portable tasks like  filterset, delete, mkdir, and copy in ant --- i.e. not the same macro definition in DOS and in a unixy shell, but that reasoning is quite unstatisfactory, because that means that every time you are considering a new shell you will need to create again such a set of macros --- or better, user defined function that one would $(call ...).
So, you may argue that the real problem is that Makefile call some bash commands, but I am more opinionated that the real problem is that GNU Make is missing the builtin features that would allow one to do without those bash command in the statements in a standard way, and without user defined macros/function to ensure portability. 
> 
> > 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.
[... 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.
> > 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.)>
Ok, I see, unless if you do the 's/find-this/replace-by-that/g' with some other character than `/', e.g. like that 's!find-this!replace-by-that!g'  
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 ?
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 ...
> 
> > 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.  
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
> 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.
> 
But then that kind of mean using the same sort of tricks to which I resorted to compile with MSYS. I was also doing those subst to have the backslashes in the first place and be sure that no problem would happen become some SW (be it MSYS or EMACS) would do some mistake in badly converting forward slashed to backward slashes
> 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.
> 
I would be more than quite happy to believe you, but it seems that I don't have enough expertize in GNU make for having this belief. And, this lack of expertize --- of lack of things up the sleeve of GNU make, let us see --- is not just mine: see it, CEDET's Makefile's are not portable to DOS according to your criterion that the real problem is the use of Bash commands. E.g. CEDET Makefile's call bash specific command `if [ -f .... ]; then ... fi'. But surely CEDET people who created EDE know far more about writing Makefiles than I do. However CEDET's Makefile could be portable to Win32 if you take it for granted that GNU Make cannot leave without some Unixy shell nearby --- so MSYS under MSWindow ---, and therefore that the only remaining issue is path manipulation. Hence the FS, CFS, pathconvert and cpathconvert which I was suggesting.
VBR,   Vincent.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 13871 bytes --]

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, "deng@randomsample.de"
> 	<deng@randomsample.de>, emacs-devel <emacs-devel@gnu.org>
> Date: Sat, 6 Oct 2012 23:41:21 +0200
> 
> Well, call this the "real problems" if you like, I am slightly sceptical on what the real problem really is, most Makefiles I have seen in my life are delegating some file manipulation tasks to some bash shell.

That's because most projects cannot assume GNU Make.  But for building
on MS-Windows with GNU tools, you _can_ assume that.

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

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

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

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

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.

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

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

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

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]


[... SNIP ...]
> 

> As you can see in nt/INSTALL, using the MSYS shell is not supported by
> the Windows Makefile's used to build Emacs.  I occasionally hear
> reports that someone succeeded to build using MSYS anyway, so I guess
> with enough tweaking it can work.  But it isn't supported.
>  


[... SNIP ...]



Yes, but on the other hand here is what I get when I am using configure.bat from a cmd.exe console


make.exe[5]: Entering directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Demacs=1 -I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/make-docfile.o make-docfile.c
make-docfile.c:37:20: fatal error: config.h: No such file or directory
compilation terminated.
make.exe[5]: *** [oo-spd/i386/make-docfile.o] Error 1



It seems that for some reason there is not any any `-I ../src' flags to gcc...


   Vincent.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1368 bytes --]

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "deng@randomsample.de" <deng@randomsample.de>,
> 	"cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>
> Date: Sun, 7 Oct 2012 09:52:02 +0200
> 
> > As you can see in nt/INSTALL, using the MSYS shell is not supported by
> > the Windows Makefile's used to build Emacs.  I occasionally hear
> > reports that someone succeeded to build using MSYS anyway, so I guess
> > with enough tweaking it can work.  But it isn't supported.
> >  
> 
> 
> [... SNIP ...]
> 
> 
> 
> Yes, but on the other hand here is what I get when I am using configure.bat from a cmd.exe console
> 
> 
> make.exe[5]: Entering directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
> mkdir "oo-spd"
> mkdir "oo-spd/i386"
> echo oo-spd/i386 > stamp_BLD
> gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Demacs=1 -I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/make-docfile.o make-docfile.c
> make-docfile.c:37:20: fatal error: config.h: No such file or directory
> compilation terminated.
> make.exe[5]: *** [oo-spd/i386/make-docfile.o] Error 1
> 
> 
> 
> It seems that for some reason there is not any any `-I ../src' flags to gcc...

Not here:

  gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -fno-crossjumping  -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1 -DNO_LDAV=1 -DNO_ARCHIVES=1 -I../lib  -I../nt/inc -I../src -DUSE_CRT_DLL=1 -o oo/i386/make-docfile.o make-docfile.c
                                                                                                                                                       ^^^^^^^^

Maybe this is because you are using the MSYS Make.  Don't.  Use the
MinGW Make instead.

Also, what kind of message is "compilation terminated"?  Is your GCC
also an MSYS GCC, perhaps?

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]


[... SNIP ...]
> 

> Not here:
> 
>   gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -fno-crossjumping  -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1 -DNO_LDAV=1 -DNO_ARCHIVES=1 -I../lib  -I../nt/inc -I../src -DUSE_CRT_DLL=1 -o oo/i386/make-docfile.o make-docfile.c
>                                                                                                                                                        ^^^^^^^^
> 
> Maybe this is because you are using the MSYS Make.  Don't.  Use the
> MinGW Make instead.
> 
> Also, what kind of message is "compilation terminated"?  Is your GCC
> also an MSYS GCC, perhaps?
> 
> 
> 



Here is what I get with 


mingw32-make.exe bootstrap MAKE=mingw32-make.exe


, in a cmd.exe console, but with still MSYS in my path (for rm and such likes):


mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I ../src -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src  -o oo-spd/i386/make-docfile.o make-docfile.c
In file included from ../src/config.h:1673:0,
                 from make-docfile.c:37:
../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory



For some reason -I ../nt/inc is dropped, well I could just add --cflags -I   --cflags ../nt/inc  the call of configure.bat. 


My gcc is that from MingW32, and yes, AFAIK, it should MSYS compatible, but why should that matter: I understand that MSYS application are able to work like native MSWindows application, just the opposite is not possible.


Yes the "compilation terminated" message is from GCC, here is an experiment under a BASH shell to prove it:


/c/Programme/GNU/installation/emacs-install/emacs/trunk/src>cat > junk.c <<EOF
> #include <nowhere.h>
> void main(){}
> EOF
/c/Programme/GNU/installation/emacs-install/emacs/trunk/src>gcc junk.c
junk.c:1:21: fatal error: nowhere.h: No such file or directory
compilation terminated.



VBR,
   Vincent.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2526 bytes --]

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 8563 bytes --]





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

 		 	   		  

[-- Attachment #2: Type: text/html, Size: 9667 bytes --]

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, "deng@randomsample.de"
> 	<deng@randomsample.de>, emacs-devel <emacs-devel@gnu.org>
> Date: Sun, 7 Oct 2012 13:49:19 +0200
> 
> Here is what I get with 
> 
> mingw32-make.exe bootstrap MAKE=mingw32-make.exe
> 
> , in a cmd.exe console, but with still MSYS in my path (for rm and such likes):

Keeping MSYS on PATH is a mistake, see below.

> mkdir "oo-spd"
> mkdir "oo-spd/i386"
> echo oo-spd/i386 > stamp_BLD
> gcc -I ../src -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src  -o oo-spd/i386/make-docfile.o make-docfile.c
> In file included from ../src/config.h:1673:0,
>                  from make-docfile.c:37:
> ../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory
> 
> 
> 
> For some reason -I ../nt/inc is dropped, well I could just add --cflags -I   --cflags ../nt/inc  the call of configure.bat. 

It's MSYS again, no doubt.  Remove MSYS from PATH, and use non-MSYS rm
and cp.

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> CC: "deng@randomsample.de" <deng@randomsample.de>,
> 	"cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>, emacs-devel <emacs-devel@gnu.org>
> 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.

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

[Vincent Belaïche]

[-- Attachment #1.1: Type: text/plain, Size: 4732 bytes --]


Hello,

> Date: Sun, 7 Oct 2012 16:18:24 +0200
> From: eliz@gnu.org
> Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs	24.1
> To: vincent.b.1@hotmail.fr
> CC: deng@randomsample.de; cedet-semantic@lists.sourceforge.net; emacs-devel@gnu.org
> 
> > From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> > CC: "cedet-semantic@lists.sourceforge.net"
> > 	<cedet-semantic@lists.sourceforge.net>, "deng@randomsample.de"
> > 	<deng@randomsample.de>, emacs-devel <emacs-devel@gnu.org>
> > Date: Sun, 7 Oct 2012 13:49:19 +0200
> > 
> > Here is what I get with 
> > 
> > mingw32-make.exe bootstrap MAKE=mingw32-make.exe
> > 
> > , in a cmd.exe console, but with still MSYS in my path (for rm and such likes):
> 
> Keeping MSYS on PATH is a mistake, see below.
> 
> > mkdir "oo-spd"
> > mkdir "oo-spd/i386"
> > echo oo-spd/i386 > stamp_BLD
> > gcc -I ../src -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include -I c:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src  -o oo-spd/i386/make-docfile.o make-docfile.c
> > In file included from ../src/config.h:1673:0,
> >                  from make-docfile.c:37:
> > ../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory
> > 
> > 
> > 
> > For some reason -I ../nt/inc is dropped, well I could just add --cflags -I   --cflags ../nt/inc  the call of configure.bat. 
> 
> It's MSYS again, no doubt.  Remove MSYS from PATH, and use non-MSYS rm
> and cp.
> 
> 

I just did that, I installed gnuwin32 into c:/msys/1.0/gnuwin32 (well it may seem a stange location, but I have mingw32 also under msys/1.0, so why not), and I am still getting this:
rm stamp_BLD
mingw32-make.exe[1]: Leaving directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
mingw32-make.exe   -C ../lib-src make-docfile
mingw32-make.exe[1]: Entering directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I ../src -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -I C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include -I C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src  -o oo-spd/i386/make-docfile.o make-docfile.c
In file included from ../src/config.h:1673:0,
                 from make-docfile.c:37:
../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory
compilation terminated.
mingw32-make.exe[1]: *** [oo-spd/i386/make-docfile.o] Error 1

Id est, for some mysterious reason -I ../nt/inc again disappeared. The batch file that makes this is the following (with some simplification):
SET PATH=C:\Programme\GNU\installation\emacs-install\libXpm-3.5.7\src;C:\msys\1.0\mingw\bin;C:\msys\1.0\gnuwin32\bin;C:\WINDOWS\system32;C:\WINDOWS
CALL configure.bat --prefix=C:\Programme\GNU\Emacs --without-jpeg --without-tiff --without-gif --without-png  --distfiles C:\Programme\GNU\installation\emacs-install\libXpm-3.5.7\src --cflags -I --cflags "C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include" --cflags -I --cflags "C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src"
mingw32-make.exe bootstrap MAKE=mingw32-make.exe


Based on your feedback that making EMACS an MSYS application would be ok only if one would not mind a second emacs just to byte compile a few file, and that GNUWin32's rm & cp are preferable to MSYS's ones, I am now realizing that I was in complete misconception about what MSYS is. I thought that MSYS applications could behave like native Win32 applications when launched outside MSYS. But, best is to quote what MSYS's itself says c.f. http://www.mingw.org/wiki/MSYS 
Building for MSYS

To build an application for MSYS (as opposed to using MSYS), users will need to install the MSYS Toolchain. It contains headers and libraries for MSYS along with a patched version of GCC and Binutils. See HOWTO Create an MSYS Build Environment.

It should never be treated as a targeted platform. It is meant only as a means to update the MSYS components or the MSYS runtime DLL itself. Resulting programs will only run under MSYS. 
Actually my misconception stems from this I used MSYS applications quite often outside MSYS and everything worked quite well...
Anyway, thank you very much for your patience.
I am now starting to wonder whether all my troubles aren't coming from this that I may have mistakenly some components of my supposedly MingW32 toolchain patched to build for MSYS, rather than to use MSYS. How can one detect that?...
VBR,    Vincent.
PS: for completeness, I attached a tarzip with the complete compile.log and the batch script
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 5731 bytes --]

[-- Attachment #2: compile.tgz --]
[-- Type: application/x-gzip, Size: 2518 bytes --]

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

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> Date: Sun, 7 Oct 2012 18:37:11 +0200
> Cc: "cedet-semantic@lists.sourceforge.net"
> 	<cedet-semantic@lists.sourceforge.net>,
> 	"deng@randomsample.de" <deng@randomsample.de>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> rm stamp_BLD
> mingw32-make.exe[1]: Leaving directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
> mingw32-make.exe   -C ../lib-src make-docfile
> mingw32-make.exe[1]: Entering directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
> mkdir "oo-spd"
> mkdir "oo-spd/i386"
> echo oo-spd/i386 > stamp_BLD
> gcc -I ../src -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -I C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include -I C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src  -o oo-spd/i386/make-docfile.o make-docfile.c
> In file included from ../src/config.h:1673:0,
>                  from make-docfile.c:37:
> ../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory
> compilation terminated.
> mingw32-make.exe[1]: *** [oo-spd/i386/make-docfile.o] Error 1
> 
> Id est, for some mysterious reason -I ../nt/inc again disappeared. The batch file that makes this is the following (with some simplification):
> SET PATH=C:\Programme\GNU\installation\emacs-install\libXpm-3.5.7\src;C:\msys\1.0\mingw\bin;C:\msys\1.0\gnuwin32\bin;C:\WINDOWS\system32;C:\WINDOWS
> CALL configure.bat --prefix=C:\Programme\GNU\Emacs --without-jpeg --without-tiff --without-gif --without-png  --distfiles C:\Programme\GNU\installation\emacs-install\libXpm-3.5.7\src --cflags -I --cflags "C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/include" --cflags -I --cflags "C:/Programme/GNU/installation/emacs-install/libXpm-3.5.7/src"
> mingw32-make.exe bootstrap MAKE=mingw32-make.exe

I have no idea what's going on there.  What version of Emacs is that?
The compilation switches passed to GCC are nowhere near what I'd
expect given the value of LOCAL_FLAGS in lib-src/makefile.w32-in.

> I am now starting to wonder whether all my troubles aren't coming from this that I may have mistakenly some components of my supposedly MingW32 toolchain patched to build for MSYS, rather than to use MSYS. How can one detect that?...

Look inside the .exe with some dependency checker; if you see a
dependency on MSYS-1.0.DLL, it's an MSYS executable.

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

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]



[ ... SNIP ...]
> 

> I have no idea what's going on there.  What version of Emacs is that?
> The compilation switches passed to GCC are nowhere near what I'd
> expect given the value of LOCAL_FLAGS in lib-src/makefile.w32-in.
>


I have reloaded a full trunk branch, and the problem is gone, seems that somehow something was corrupted in my tree.




> > I am now starting to wonder whether all my troubles aren't coming from this that I may have mistakenly some components of my supposedly MingW32 toolchain patched to build for MSYS, rather than to use MSYS. How can one detect that?...
> 
> Look inside the .exe with some dependency checker; if you see a
> dependency on MSYS-1.0.DLL, it's an MSYS executable.
> 
> 



Thanks, I have downloaded dependency walker.


Very best regards and many thanks for all the help and teaching me about MSYS and EMACS building way for MSWindows.


  Vincent.

 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1276 bytes --]