From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?B?VmluY2VudCBCZWxh72NoZQ==?= Newsgroups: gmane.emacs.semantic,gmane.emacs.devel Subject: Re: Latest CEDET on BZR does not compile with emacs 24.1 Date: Fri, 5 Oct 2012 07:18:53 +0200 Message-ID: References: <80627pfvx8.fsf@gmail.com>, , <87k3vhesof.fsf@randomsample.de>, , <877grgdmcd.fsf@randomsample.de>, , <87mx0bcioh.fsf@randomsample.de>, , <87sj9yb4kw.fsf@randomsample.de>, , <83obkka8c8.fsf@gnu.org>, , <83mx038fm8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1378156881152018890==" X-Trace: ger.gmane.org 1349414349 10521 80.91.229.3 (5 Oct 2012 05:19:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2012 05:19:09 +0000 (UTC) Cc: "cedet-semantic@lists.sourceforge.net" , emacs-devel To: Eli Zaretskii , "deng@randomsample.de" Original-X-From: cedet-semantic-bounces@lists.sourceforge.net Fri Oct 05 07:19:15 2012 Return-path: Envelope-to: sf-cedet-semantic@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TK0Jd-0007hG-PJ for sf-cedet-semantic@m.gmane.org; Fri, 05 Oct 2012 07:19:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-1.b.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TK0JR-0000Va-5Z; Fri, 05 Oct 2012 05:19:01 +0000 Original-Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TK0JQ-0000VU-6u for cedet-semantic@lists.sourceforge.net; Fri, 05 Oct 2012 05:19:00 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of hotmail.fr designates 157.55.1.141 as permitted sender) client-ip=157.55.1.141; envelope-from=vincent.b.1@hotmail.fr; helo=dub0-omc2-s2.dub0.hotmail.com; Original-Received: from dub0-omc2-s2.dub0.hotmail.com ([157.55.1.141]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TK0JP-00031z-3l for cedet-semantic@lists.sourceforge.net; Fri, 05 Oct 2012 05:19:00 +0000 Original-Received: from DUB102-W38 ([157.55.1.136]) by dub0-omc2-s2.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 22:18:53 -0700 X-Originating-IP: [92.135.119.148] Importance: Normal In-Reply-To: <83mx038fm8.fsf@gnu.org> X-OriginalArrivalTime: 05 Oct 2012 05:18:53.0435 (UTC) FILETIME=[E93C7CB0:01CDA2B8] X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [157.55.1.141 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (vincent.b.1[at]hotmail.fr) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (vincent.b.1[at]hotmail.fr) 1.0 HTML_MESSAGE BODY: HTML included in message -0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TK0JP-00031z-3l X-BeenThere: cedet-semantic@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cedet-semantic-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.semantic:3014 gmane.emacs.devel:154078 Archived-At: --===============1378156881152018890== Content-Type: multipart/alternative; boundary="_5f29f618-e598-416a-9b66-959a904bb026_" --_5f29f618-e598-416a-9b66-959a904bb026_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C 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 path= s like /c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddef= s.el=2C but the same kind of path that pwd -W outputs=2C i.e. c:/Programme/= GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el for the same fi= le. EMACS is supposed to understand that kind of path. However that still d= oes not work: Here is the beginning of the mingw32-make output ----------------------------------------------------------------------- Emacs version: 24.1.1 nil on windows-nt=20 Removing loaddefs.el files from subprojects. Generating autoloads. mingw32-make[1]: Entering directory `c:/Programme/GNU/installation/cedet-in= stall/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/installat= ion/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 fi= le or directory" "d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c=3Bc:msys= .0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs.el") write-region("=3B=3B=3B c=3Bc:msys.0ProgrammeGNUinstallationcedet-install= cedetlispcedetloaddefs.el --- automatically extracted autoloads\n=3B=3B\n= =3B=3B=3B Code:\n\n\f\n(provide 'c=3Bc:msys.0ProgrammeGNUinstallationcedet-= installcedetlispcedetloaddefs)\n=3B=3B Local Variables:\n=3B=3B version-con= trol: never\n=3B=3B no-byte-compile: t\n=3B=3B no-update-autoloads: t\n=3B= =3B coding: utf-8\n=3B=3B End:\n=3B=3B=3B c=3Bc:msys.0ProgrammeGNUinstallat= ioncedet-installcedetlispcedetloaddefs.el ends here\n" nil "d:/devel/emacs/= release/emacs24/emacs-24.1/lisp/c=3Bc:msys.0ProgrammeGNUinstallationcedet-i= nstallcedetlispcedetloaddefs.el") autoload-ensure-default-file("d:/devel/emacs/release/emacs24/emacs-24.1/l= isp/c=3Bc:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetloaddefs= .el") autoload-find-generated-file() update-directory-autoloads("c:/Programme/GNU/installation/cedet-install/c= edet/lisp/cedet") apply(update-directory-autoloads "c:/Programme/GNU/installation/cedet-ins= tall/cedet/lisp/cedet") batch-update-autoloads() command-line-1(("--eval" "(setq debug-on-error t)" "-l" "../../cedet-remo= ve-builtin.el" "-L" "../eieio/" "-L" "./" "-L" "./" "--eval" "(setq generat= ed-autoload-file \"c=3Bc:\\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-ins= tall/cedet/lisp/cedet' ----------------------------------------------------------------------- What happens is that path `c:/Programme/GNU/installation/cedet-install/ced= et/lisp/cedet/loaddefs.el' in the command line transformed by EMACS into `= c=3Bc:\msys\1.0\Programme\GNU\installation\cedet-install\cedet\lisp\cedet\l= oaddefs.el'. Probably the reason for doing that is quite valid: the path sh= ould have been ` c:\Programme\GNU\installation\cedet-install\cedet\lisp\ced= et\loaddefs.el' in the first place. So I would not conclude that EMACS is the one to blame=2C EMACS is just try= ing to survive in the adverse MSWindows environment by doing some tricks=2C= which besides shows that EMACS has some awareness that MSYS is installed o= n the machine (probably through the MSYS environment variable that is defin= ed to `c:\msys\1.0\'. My thought are rather that is it hard to write makefi= le that are portable because GNU Make is lacking the following features: - a predefined variable=2C e.g. $(FS) expanding to the file separator=2C i.= e. \ for MSWindows and / for Unixy shell - a predefined variable=2C e.g. $(CFS)=2C expanding to the file separator w= ithin a C-string-like environment=2C i.e. \\ for MSWindows and / for Unixy = shell=20 - a function=2C e.g. $(pathconvert ...) to convert a path name in the the U= nixy like format that make internally uses with wildcards and $(abspath ...= ) returned value into the format used on the platform where make is running= =2C i.e. in my case `c:/Programme/GNU/installation/cedet-install/cedet/lis= p/cedet/loaddefs.el' would be converted to `c:\Programme\GNU\installation\= cedet-install\cedet\lisp\cedet\loaddefs.el' - and a function=2C e.g. $(cpathconvert ...) which would do the same thing = but with output to go within some C-string-like environement=2C i.e. in my = case=20 `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' = would be converted to `c:\\Programme\\GNU\\installation\\cedet-install\\c= edet\\lisp\\cedet\\loaddefs.el' Without those basic things=2C one has no other resorts than the kind of tr= icks which I played to make the Makefile platform independent=2C and which= =2C I agree=2C may be fragile=2C though working ones. Please note that this is why I mentioned ant: in contrast to GNU Make=2C an= t has that sort of tricks that allow to do path name manipulations. VBR=2C Vincent.=20 = --_5f29f618-e598-416a-9b66-959a904bb026_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=2C


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 do= es not use MSYS paths like /c/Programme/GNU/installation/cedet-install/cede= t/lisp/cedet/loaddefs.el=2C but the same kind of path that pwd -W outputs= =2C i.e. c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loadd= efs.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.<= br>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-remov= e-builtin.el" -L ../eieio/ -L ./ -L ./ --eval '(setq generated-autoload-fil= e "c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.e= l")' -f batch-update-autoloads 'c:/Programme/GNU/installation/cedet-install= /cedet/lisp/cedet'
Debugger entered--Lisp error: (file-error "Opening ou= tput file" "no such file or directory" "d:/devel/emacs/release/emacs24/emac= s-24.1/lisp/c=3Bc:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedet= loaddefs.el")
write-region("=3B=3B=3B c=3Bc:msys.0ProgrammeGNUinstalla= tioncedet-installcedetlispcedetloaddefs.el --- automatically extracted auto= loads\n=3B=3B\n=3B=3B=3B Code:\n\n\f\n(provide 'c=3Bc:msys.0ProgrammeGNUins= tallationcedet-installcedetlispcedetloaddefs)\n=3B=3B Local Variables:\n=3B= =3B version-control: never\n=3B=3B no-byte-compile: t\n=3B=3B no-update-aut= oloads: t\n=3B=3B coding: utf-8\n=3B=3B End:\n=3B=3B=3B c=3Bc:msys.0Program= meGNUinstallationcedet-installcedetlispcedetloaddefs.el ends here\n" nil "d= :/devel/emacs/release/emacs24/emacs-24.1/lisp/c=3Bc:msys.0ProgrammeGNUinsta= llationcedet-installcedetlispcedetloaddefs.el")
autoload-ensure-defaul= t-file("d:/devel/emacs/release/emacs24/emacs-24.1/lisp/c=3Bc:msys.0Programm= eGNUinstallationcedet-installcedetlispcedetloaddefs.el")
autoload-find= -generated-file()
update-directory-autoloads("c:/Programme/GNU/install= ation/cedet-install/cedet/lisp/cedet")
apply(update-directory-autoload= s "c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet")
batc= h-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=3Bc:\\msys\\1.0\\Programme\\G= NU\\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-ma= ke[1]: *** [autoloads] Error -1
mingw32-make[1]: Leaving directory `c:/P= rogramme/GNU/installation/cedet-install/cedet/lisp/cedet'

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


What happens is that path =3B `c:/Programme/GNU/installatio= n/cedet-install/cedet/lisp/cedet/loaddefs.el' in the command line transform= ed by EMACS into  =3B`c=3Bc:\msys\1.0\Programme\GNU\installation\cedet-= install\cedet\lisp\cedet\loaddefs.el'. Probably the reason for doing that i= s quite valid: the path should have been ` c:\Programme\GNU\installation\ce= det-install\cedet\lisp\cedet\loaddefs.el' in the first place.


So= I would not conclude that EMACS is the one to blame=2C EMACS is just tryin= g to survive in the adverse MSWindows environment by doing some tricks=2C w= hich 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:
<= br>
- a predefined variable=2C e.g. $(FS) expanding to the file separato= r=2C i.e. \ for MSWindows and / for Unixy shell
- a predefined variable= =2C e.g. $(CFS)=2C expanding to the file separator within a C-string-like e= nvironment=2C i.e. \\ for MSWindows and / for Unixy shell =3B
- a fu= nction=2C e.g. $(pathconvert ...) to convert a path name in the the Unixy l= ike format that make internally uses with wildcards and $(abspath ...) retu= rned value into the format used on the platform where make is running=2C i.= e. in my case =3B `c:/Programme/GNU/installation/cedet-install/cedet/li= sp/cedet/loaddefs.el' would be converted to  =3B`c:\Programme\GNU\insta= llation\cedet-install\cedet\lisp\cedet\loaddefs.el'
- and a function=2C = e.g. $(cpathconvert ...) which would do the same thing but with output to g= o within some C-string-like environement=2C i.e. in my case =3B `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs.el' = would be converted to  =3B `c:\\Programme\\GNU\\installation\\cedet-ins= tall\\cedet\\lisp\\cedet\\loaddefs.el'


Without those basic things=2C one has no other resorts than the= kind  =3Bof tricks which I played to make the Makefile platform indepe= ndent=2C and which=2C I agree=2C may be fragile=2C though working ones.
=

Please note that this is why I mentioned ant: in contrast to GNU Ma= ke=2C ant has that sort of tricks that allow to do path name manipulations.=


VBR=2C
 =3B  =3BVincent. =3B

=
= --_5f29f618-e598-416a-9b66-959a904bb026_-- --===============1378156881152018890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ 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 --===============1378156881152018890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cedet-semantic mailing list cedet-semantic@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cedet-semantic --===============1378156881152018890==--