From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dani Moncayo Newsgroups: gmane.emacs.bugs Subject: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" Date: Thu, 22 Nov 2012 20:16:18 +0100 Message-ID: References: <83a9uauwwo.fsf@gnu.org> <83zk29tvo8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1353611808 23984 80.91.229.3 (22 Nov 2012 19:16:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Nov 2012 19:16:48 +0000 (UTC) Cc: 12955@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 22 20:16:57 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 1TbcGe-0001aH-Iz for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2012 20:16:56 +0100 Original-Received: from localhost ([::1]:50859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbcGT-0006Nf-TC for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2012 14:16:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbcGQ-0006NV-Im for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 14:16:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbcGP-0000DT-8g for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 14:16:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbcGP-0000DM-4y for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 14:16:41 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TbcHh-0002lu-Qg for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2012 14:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dani Moncayo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Nov 2012 19:18: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.135361186410627 (code B ref 12955); Thu, 22 Nov 2012 19:18:01 +0000 Original-Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 19:17:44 +0000 Original-Received: from localhost ([127.0.0.1]:33516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbcHQ-0002lL-8E for submit@debbugs.gnu.org; Thu, 22 Nov 2012 14:17:44 -0500 Original-Received: from mail-oa0-f44.google.com ([209.85.219.44]:41915) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbcHN-0002lD-N1 for 12955@debbugs.gnu.org; Thu, 22 Nov 2012 14:17:43 -0500 Original-Received: by mail-oa0-f44.google.com with SMTP id n5so7941542oag.3 for <12955@debbugs.gnu.org>; Thu, 22 Nov 2012 11:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MMwJ3AfP4z1QGSCKUkdSAvK9Rk4y+HXKghEkY74K5Ww=; b=cnFe0MvJJsNJhHfPP97cAW6LNVkL3hY/6I6KpAP9F6nkS4toEts8RInWw2Cp4L5AIM v6JP+by+cPIm8o8rt2Dgf0WMVZpcnJ4Cx9xmQH4Vld+42hojWARCQqubToOxwOCHX349 XmlHGrWJdeFCbUoxvGqvfN9PDc5/D8H09Elpx8pOHrtUhp+Ew/su3U/TZHSzci1yfYha /ozS1w4uZoGZU7pH5GYIBe+dibfuPF+DIvzfvkOkkjsn7tlUVlipJ81xCDSccunJDWk7 8SD+e6U1cxx9roW3iQWfEeDHS4qdhHhQ7GvcYTmB15R4CLkee4ovZdnuDlPr39QpRWtq 0+gw== Original-Received: by 10.182.21.142 with SMTP id v14mr1114564obe.46.1353611778353; Thu, 22 Nov 2012 11:16:18 -0800 (PST) Original-Received: by 10.60.64.170 with HTTP; Thu, 22 Nov 2012 11:16:18 -0800 (PST) In-Reply-To: <83zk29tvo8.fsf@gnu.org> 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:67322 Archived-At: > 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. I thought it was supported, since the makefiles do care about SHELLTYPE being CMD or SH, and since the build process work just fine with SH (modulo the problem at hand). > 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). Agreed, that is a supported way (the one that uses CMD as shell). > 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 restriction is preventing the use of the SH shell. And those two programs are included in the msys-base package of MinGW, which I find very convenient and easy to install (with its package manager). >> 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. The problems I remember are all the same: the one discussed here. But my memory is not perfect and I could be wrong. >> 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. Agreed. >> 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.). Yes that seems to work for me. I've tested both cases (SH and CMD). This is the patch I've used: === modified file 'nt/gmake.defs' --- nt/gmake.defs 2012-10-17 19:02:44 +0000 +++ nt/gmake.defs 2012-11-22 18:39:57 +0000 @@ -69,10 +69,12 @@ ifeq "$(findstring ECHO, $(sh_output))" "ECHO" THE_SHELL = $(COMSPEC)$(ComSpec) SHELLTYPE=CMD +FORWARD_SLASH=/ else USING_SH = 1 THE_SHELL = $(SHELL) SHELLTYPE=SH +FORWARD_SLASH=// endif MAKETYPE=gmake === modified file 'src/makefile.w32-in' --- src/makefile.w32-in 2012-11-17 23:16:24 +0000 +++ src/makefile.w32-in 2012-11-22 18:40:52 +0000 @@ -234,7 +234,7 @@ gl-stamp: ../lib-src/$(BLD)/make-docfile.exe $(GLOBAL_SOURCES) - $(DEL) gl-tmp "$(THISDIR)/../lib-src/$(BLD)/make-docfile" -d . -g $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp - cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" + fc.exe $(FORWARD_SLASH)b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h - $(DEL) gl-tmp echo timestamp > $@ > 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. That sounds like a good plan to me. > 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. I'm kind of a novice in these matters, but if you give me some guidelines to get started and I find enough time, I'd like to learn and try to help. Thanks. -- Dani Moncayo