From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" Date: Thu, 22 Nov 2012 19:05:43 +0200 Message-ID: <83zk29tvo8.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1353604018 19003 80.91.229.3 (22 Nov 2012 17:06:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Nov 2012 17:06:58 +0000 (UTC) Cc: 12955@debbugs.gnu.org To: Dani Moncayo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 22 18:07:08 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TbaEv-0006J8-QB for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2012 18:07:02 +0100 Original-Received: from localhost ([::1]:33331 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaEk-0003GE-Vm for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2012 12:06:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaEd-0003Ff-0R for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 12:06:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbaEa-00018B-W9 for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 12:06:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaEa-000187-SC for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 12:06:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TbaFu-0006Nr-1W for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 12:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Nov 2012 17:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12955 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12955-submit@debbugs.gnu.org id=B12955.135360407324522 (code B ref 12955); Thu, 22 Nov 2012 17:08:01 +0000 Original-Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 17:07:53 +0000 Original-Received: from localhost ([127.0.0.1]:33398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbaFk-0006NT-Hk for submit@debbugs.gnu.org; Thu, 22 Nov 2012 12:07:53 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:34995) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbaFi-0006NI-AR for 12955@debbugs.gnu.org; Thu, 22 Nov 2012 12:07:51 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDW00E00FEU8Q00@a-mtaout22.012.net.il> for 12955@debbugs.gnu.org; Thu, 22 Nov 2012 19:05:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDW00DFPFHWN3C0@a-mtaout22.012.net.il>; Thu, 22 Nov 2012 19:05:57 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67318 Archived-At: > Date: Thu, 22 Nov 2012 08:19:18 +0100 > From: Dani Moncayo > Cc: 12955@debbugs.gnu.org > > > Sorry, I don't want to do this. This might work now, but it does so > > by pure luck, and might break in some future version of cmd, because > > there _should_ be a space between /c and the command that follows. > > Is that documented somewhere? I've read the help of "cmd" and I don't see it. I do: D:\usr\eli\data>cmd /? Starts a new instance of the Windows XP command interpreter CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF] [[/S] [/C | /K] string] ^^^ > > The solution to this is simple: don't involve MSYS in building the > > native port of Emacs. It boils down to removing MSYS from PATH in the > > shell window where you run the build scripts. > > That it one possible solution, but certainly not the one I'd like to > pick up, because it imposes an unnecessary restriction on the way of > building Emacs, and this particular restriction annoys me, because > Emacs can be build on Windows using the bash sell, and I like to do > so. I don't quite understand your line of thinking. If there is an annoyance here (I don't see it), then it is self-imposed, because you are deliberately using an unsupported environment -- unsupported _precisely_ because of problems like this one. Meanwhile, a supported way of building Emacs is just one mouse click away -- start a normal cmd shell window, making sure MSYS is not on PATH, and that's it. I'm using this exclusively without any problems (although I do have MSYS installed). What restriction this presents, when it uses commands that are available out of the box on Windows (with the exception of 2 programs from a single Coreutils package)? > The only problem I've observed when doing it is the one explained > in this thread You forget the previous ones. I still remember them. > and I'd like to fix it. I don't mind fixing it, just not in the kludgey way you suggest. Playing tricks with white space and quotes is a maintenance burden in the long run: someone forgets or doesn't know about the importance of the missing blank and commits a change that breaks things. Treatment of quotes in cmd is one of the trickiest issues ever, it depends on Registry settings and the contents of the command line, so can subtly break without notice. We had a similar problem in configure.bat just a few months ago. > In the (unlikely) event that a future version of cmd.exe gives > problems when invoked that way, we could find a solution for it, but I > doubt it will ever happen. I would like to find a good solution now. Does it work for you to get rid of the "cmd /c" part entirely and remove the quotes, i.e. use this: fc.exe /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h ? (Note the ".exe" part, it's important because "fc" is a shell builtin in Bash.) If "/b" causes the same trouble as "/c" in the cmd command, we can make a Make variable, set to "//b" under MSYS and to "/b" otherwise. MSYS can be recognized by having MSYSTEM in the environment (Make converts all environment variables to Make variables, so you can use ifdef etc.). FYI, I'd like to deprecate the Unixy shell parts of the Windows makefiles some time soon, leaving only the cmd parts. Supporting 2 kinds of shells with such different semantics is a PITA. In parallel, I'd like to make it possible to configure and build a native w32 Emacs using MSYS and the mainline Unixy configury and Makefiles. When that goal is reached, the old configure.bat and makefile.w32-in's will become a fallback solution for those who cannot or don't want to install MSYS and for MSVC builds. If you or someone else wants to work on such an MSYS build, _that_ would be a worthy investment of time and energy, and an excellent use of MSYS the way MSYS is supposed to be used. When used that way, MSYS really shines. If you are willing to work on the MSYS build, I promise you all the support I can give. Otherwise, you really should start migrating to cmd.