From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.emacs.semantic Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with emacs 24.1 Date: Fri, 05 Oct 2012 10:10:38 +0200 Message-ID: <83zk41730h.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1349424647 22861 80.91.229.3 (5 Oct 2012 08:10:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2012 08:10:47 +0000 (UTC) Cc: cedet-semantic@lists.sourceforge.net, deng@randomsample.de, emacs-devel@gnu.org To: Vincent =?iso-8859-1?Q?Bela=EFche?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 05 10:10:53 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TK2zk-00016r-Qt for ged-emacs-devel@m.gmane.org; Fri, 05 Oct 2012 10:10:53 +0200 Original-Received: from localhost ([::1]:41586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK2ze-0006S4-PG for ged-emacs-devel@m.gmane.org; Fri, 05 Oct 2012 04:10:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK2zX-0006Rx-5V for emacs-devel@gnu.org; Fri, 05 Oct 2012 04:10:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK2zP-0004rh-Ng for emacs-devel@gnu.org; Fri, 05 Oct 2012 04:10:39 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:45763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK2zP-0004qe-7l for emacs-devel@gnu.org; Fri, 05 Oct 2012 04:10:31 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MBE00700UMHKC00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 05 Oct 2012 10:10:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBE0070WUPAFX50@a-mtaout21.012.net.il>; Fri, 05 Oct 2012 10:10:23 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154080 gmane.emacs.semantic:3016 Archived-At: > From: Vincent Bela=EFche > CC: "cedet-semantic@lists.sourceforge.net" > =09, emacs-devel > Date: Fri, 5 Oct 2012 07:18:53 +0200 >=20 > Thank you Eli for your kind answer. I tried it with the mingw32-mak= e 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/cede= t/lisp/cedet/loaddefs.el, but the same kind of path that pwd -W outpu= ts, 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 hav= e 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 /bi= n directory to your PATH such that even the cmd window gets that PATH, edit your environment variables and remove the MSYS /bin directory =66rom the PATH. Then these problems will go away, and you will be faced only with real problems: the Unixy features used by the Makefil= e 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/l= isp/c;c:msys.0ProgrammeGNUinstallationcedet-installcedetlispcedetload= defs.el") ^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ See this nonsense? That's MSYS file syntax conversion in action. Whenever an MSYS program (probably Bash in this case) invokes a nativ= e 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 i= s 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-ins= tall/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. Th= e 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\ce= det\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 por= table because GNU Make is lacking the following features: >=20 >=20 > - 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 invok= e 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 Mak= e variables, and expands them? > - a predefined variable, e.g. $(CFS), expanding to the file separat= or within a C-string-like environment, i.e. \\ for MSWindows and / fo= r Unixy shell=20 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 whe= re make is running, i.e. in my case `c:/Programme/GNU/installation/c= edet-install/cedet/lisp/cedet/loaddefs.el' would be converted to `c:= \Programme\GNU\installation\cedet-install\cedet\lisp\cedet\loaddefs.e= l' 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=20 > `c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loadd= efs.el' would be converted to `c:\\Programme\\GNU\\installation\\ce= det-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 Ma= ke, ant has that sort of tricks that allow to do path name manipulati= ons. GNU Make has enough up its sleeve for this job, and many similar ones= , believe me.