From unknown Sat Jun 21 03:22:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12955 <12955@debbugs.gnu.org> To: bug#12955 <12955@debbugs.gnu.org> Subject: Status: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" Reply-To: bug#12955 <12955@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:22:10 +0000 retitle 12955 24.3.50; Build process on MS-Windows: sometimes needs "human = intervention" reassign 12955 emacs submitter 12955 Dani Moncayo severity 12955 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 15:51:17 2012 Received: (at submit) by debbugs.gnu.org; 21 Nov 2012 20:51:17 +0000 Received: from localhost ([127.0.0.1]:59627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbHGO-00047n-Jd for submit@debbugs.gnu.org; Wed, 21 Nov 2012 15:51:17 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55669) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbHGM-00047g-Kj for submit@debbugs.gnu.org; Wed, 21 Nov 2012 15:51:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbHF7-00077h-7n for submit@debbugs.gnu.org; Wed, 21 Nov 2012 15:49:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:45134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbHF7-00077b-57 for submit@debbugs.gnu.org; Wed, 21 Nov 2012 15:49:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbHF6-0008SH-1a for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2012 15:49:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbHF4-00076g-RT for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2012 15:49:55 -0500 Received: from mail-ob0-f169.google.com ([209.85.214.169]:57516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbHF4-00076E-MZ for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2012 15:49:54 -0500 Received: by mail-ob0-f169.google.com with SMTP id lz20so8607436obb.0 for ; Wed, 21 Nov 2012 12:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vs93ZuN2hwDF2ZZZlJ2XZBxWEvvQ6Y13+Xlt45+aAZU=; b=T1d3g6PMe8Xj36H64PmzVqXVFjqwQXN///L6r6riiafkEhin87QCbnwlvjkarGQFST pu+3X4I3x7mm+jjSjx1E59rtTdXteuqq/kViUvFOrP0m7IWUL9/1OjaqbAsZ9wNNnFf0 GDW1yVdVwFBYcj3U1AtPbzbhrLlJnIek344N3H7borNdzMcDPq0bD10BuNnPLFBRUetE loJ5DXTeUm7Iu6zIAAJ1hIWzsvQTJ0F1d00G2diENAGAn06NmCWFPLTluYg+RDSOzEyv NmZ5NcHiCL8gNrT5z18KvUxxdPV/VCmuB7BFjUko1LUvI18/PU7Hn9yegy0qvUldNEfS /GLw== MIME-Version: 1.0 Received: by 10.182.78.137 with SMTP id b9mr17497280obx.94.1353530993636; Wed, 21 Nov 2012 12:49:53 -0800 (PST) Received: by 10.60.64.170 with HTTP; Wed, 21 Nov 2012 12:49:53 -0800 (PST) Date: Wed, 21 Nov 2012 21:49:53 +0100 Message-ID: Subject: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" From: Dani Moncayo To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Hello, Sometimes, when building the trunk on MS-Windows, the make process get stuck when this like of `src/makefile' is executed: cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" What happens is that a new cmd.exe session is open and waiting for input, when the expected behavior for that session is to execute the command between double quotes and exit. So I have to copy&paste the command, execute it and exit the cmd session so that the build process can continue. This problem is known to Eli, Juanma and those who build Emacs on Windows, and is related to MSYS and the translation it performs with filesystem paths ("/c" is translated to "c:\" for example). If you have MSYS installed in your system, it is easy to reproduce the problem: 1. Open a cmd.exe console. 2. Run: sh (to start a bash session). 3. Run: cmd /c "dir". --> A new cmd session is created, it is waiting for input and the "dir" command has not been executed. Fortunately, I just found a solution for this: just remove the space between the `/c' and the double quote: 3. Run: cmd /c"dir". --> This time the cmd session executes the "dir" command and then ends, returning control to the bash session. So, please, apply the following patch to the trunk for fixing this problem (I've just tested it): === modified file 'src/makefile.w32-in' --- src/makefile.w32-in 2012-11-17 23:16:24 +0000 +++ src/makefile.w32-in 2012-11-21 20:21:30 +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" + cmd /c"fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" - $(DEL) gl-tmp echo timestamp > $@ Thanks. In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601) of 2012-11-21 on MS-W7-DANI Bzr revision: 110971 monnier@iro.umontreal.ca-20121121163435-89teaio2wo47frly Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include' -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 17:45:07 2012 Received: (at 12955) by debbugs.gnu.org; 21 Nov 2012 22:45:07 +0000 Received: from localhost ([127.0.0.1]:59788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbJ2Z-0007Zo-3X for submit@debbugs.gnu.org; Wed, 21 Nov 2012 17:45:07 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:57219) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbJ2W-0007Zg-P7 for 12955@debbugs.gnu.org; Wed, 21 Nov 2012 17:45:06 -0500 Received: by mail-ob0-f172.google.com with SMTP id ef5so7249110obb.3 for <12955@debbugs.gnu.org>; Wed, 21 Nov 2012 14:43:46 -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 :content-type; bh=u7QSsq71jjKuvAHWJKaeo8/E/oMpi6ejSyZp50NBvo0=; b=iP/o2k4BFQClQm7w7P9YJhRx//eJd4Ixx2o2Mp7jh/mUuB8OohKlUriOKVYb7OgTJO SWzuq5IatpMMjmstbc1lPo7Qwe8IdfnZ+89ytJg9nYOl9A5HFKSomBCy89dynhBZDCLb qZ3/sJjmCKaL/SSb+gdwY0/DWEQBTaZlwgJUr7/1bjEQCwgSouIB2tAnQxNrrQ4uacAy Ctm2HhDwP1inESh6RtGc52p32lcZF+vId1UYN64WShiQ5yml5oKEKxO6ICaeH/1FjaaE FP7jrYZwfEottPYOFj8itRkSo/A0P/nxehvGtTFZeVL3g9PCzZk9e4Fv1nxhhgXtknS8 eQcA== MIME-Version: 1.0 Received: by 10.60.32.210 with SMTP id l18mr14123124oei.99.1353537825153; Wed, 21 Nov 2012 14:43:45 -0800 (PST) Received: by 10.60.64.170 with HTTP; Wed, 21 Nov 2012 14:43:45 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Nov 2012 23:43:45 +0100 Message-ID: Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" From: Dani Moncayo To: 12955@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12955 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) > $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp > - cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" > + cmd /c"fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" > - $(DEL) gl-tmp > echo timestamp > $@ I've grepped the sources and there is another instance of this problem, in that same file (src/makefile.w32-in): @cmd /c rem true This sentence must not be executed in my current builds because I've not had to touch it for my build to succeeded. But if the sentence is executed under some circumstances, the same problem will crop up. So here is a new version of the patch which fixed that case too and includes an informative commentary: === modified file 'src/makefile.w32-in' --- src/makefile.w32-in 2012-11-17 23:16:24 +0000 +++ src/makefile.w32-in 2012-11-21 22:42:06 +0000 @@ -228,13 +228,17 @@ xterm.o xfns.o xmenu.o xselect.o xrdb.o xsmfns.o dbusbind.o obj = $(GLOBAL_SOURCES:.c=.o) +# WARNING: Every `cmd /c' command must have the form: +# cmd /c"some-command" +# without any space between the /c and the first double quote. +# This is needed to avoid problems when sh.exe is used as shell. globals.h: gl-stamp - @cmd /c rem true + @cmd /c"rem true" 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" + cmd /c"fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" - $(DEL) gl-tmp echo timestamp > $@ -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 22:43:08 2012 Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 03:43:08 +0000 Received: from localhost ([127.0.0.1]:60071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbNgx-0007tr-Qw for submit@debbugs.gnu.org; Wed, 21 Nov 2012 22:43:08 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:35021) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbNgt-0007tg-Dd for 12955@debbugs.gnu.org; Wed, 21 Nov 2012 22:43:05 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDV00400E86EN00@a-mtaout22.012.net.il> for 12955@debbugs.gnu.org; Thu, 22 Nov 2012 05:41:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDV004W9E9I7540@a-mtaout22.012.net.il>; Thu, 22 Nov 2012 05:41:43 +0200 (IST) Date: Thu, 22 Nov 2012 05:41:27 +0200 From: Eli Zaretskii Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <83a9uauwwo.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 21 Nov 2012 21:49:53 +0100 > From: Dani Moncayo > > Sometimes, when building the trunk on MS-Windows, the make process get > stuck when this like of `src/makefile' is executed: > > cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" > > What happens is that a new cmd.exe session is open and waiting for > input, when the expected behavior for that session is to execute the > command between double quotes and exit. So I have to copy&paste the > command, execute it and exit the cmd session so that the build process > can continue. > > This problem is known to Eli, Juanma and those who build Emacs on > Windows, and is related to MSYS and the translation it performs with > filesystem paths ("/c" is translated to "c:\" for example). > > If you have MSYS installed in your system, it is easy to reproduce the problem: > 1. Open a cmd.exe console. > 2. Run: sh (to start a bash session). > 3. Run: cmd /c "dir". > > --> A new cmd session is created, it is waiting for input and the > "dir" command has not been executed. > > Fortunately, I just found a solution for this: just remove the space > between the `/c' and the double quote: > 3. Run: cmd /c"dir". > > --> This time the cmd session executes the "dir" command and then > ends, returning control to the bash session. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 21 Nov 2012 21:49:53 +0100 > From: Dani Moncayo > > Sometimes, when building the trunk on MS-Windows, the make process get > stuck when this like of `src/makefile' is executed: > > cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" > > What happens is that a new cmd.exe session is open and waiting for > input, when the expected behavior for that session is to execute the > command between double quotes and exit. So I have to copy&paste the > command, execute it and exit the cmd session so that the build process > can continue. > > This problem is known to Eli, Juanma and those who build Emacs on > Windows, and is related to MSYS and the translation it performs with > filesystem paths ("/c" is translated to "c:\" for example). > > If you have MSYS installed in your system, it is easy to reproduce the problem: > 1. Open a cmd.exe console. > 2. Run: sh (to start a bash session). > 3. Run: cmd /c "dir". > > --> A new cmd session is created, it is waiting for input and the > "dir" command has not been executed. > > Fortunately, I just found a solution for this: just remove the space > between the `/c' and the double quote: > 3. Run: cmd /c"dir". > > --> This time the cmd session executes the "dir" command and then > ends, returning control to the bash session. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4972] > Date: Wed, 21 Nov 2012 21:49:53 +0100 > From: Dani Moncayo > > Sometimes, when building the trunk on MS-Windows, the make process get > stuck when this like of `src/makefile' is executed: > > cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || $(CP) gl-tmp globals.h" > > What happens is that a new cmd.exe session is open and waiting for > input, when the expected behavior for that session is to execute the > command between double quotes and exit. So I have to copy&paste the > command, execute it and exit the cmd session so that the build process > can continue. > > This problem is known to Eli, Juanma and those who build Emacs on > Windows, and is related to MSYS and the translation it performs with > filesystem paths ("/c" is translated to "c:\" for example). > > If you have MSYS installed in your system, it is easy to reproduce the problem: > 1. Open a cmd.exe console. > 2. Run: sh (to start a bash session). > 3. Run: cmd /c "dir". > > --> A new cmd session is created, it is waiting for input and the > "dir" command has not been executed. > > Fortunately, I just found a solution for this: just remove the space > between the `/c' and the double quote: > 3. Run: cmd /c"dir". > > --> This time the cmd session executes the "dir" command and then > ends, returning control to the bash session. 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 22 02:20:45 2012 Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 07:20:46 +0000 Received: from localhost ([127.0.0.1]:60205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbR5U-00062e-Ec for submit@debbugs.gnu.org; Thu, 22 Nov 2012 02:20:45 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:32935) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbR5S-00062X-7s for 12955@debbugs.gnu.org; Thu, 22 Nov 2012 02:20:38 -0500 Received: by mail-ob0-f172.google.com with SMTP id ef5so7494793obb.3 for <12955@debbugs.gnu.org>; Wed, 21 Nov 2012 23:19:18 -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=Gi0psaDBL1SLiUOzhIQTme5QmyU3TOFKAjE6MH63PMo=; b=p+Fffhp+imuOatIiTeg9vNU1nQ07eiwnOSiD3UTzrSUTVDbqKP/HZTvDhIGGEdsg/h V97U69Nl92vQpmbBWvnt27Ie6v5KteEUVeGWJJZ35Zi1t37tm3lTZc5nIbE4Ka/U3NEX G4KERZ0hp+ngpz45wujVp9PWse4BmCX6JMVPYuz4KSBD4MwbjQkWe4B+ILQ9VE7MFhLJ te0LYeAgFjO2oGzzmmxfp31oykbbfUCL1VE9tdnUHr9dMGdC0q5xvWG8AUpmLYJVx1ND iavv3+KErUR3e80h3kANrKyJWSjkEjXf6th4tt08uayvk8R2Dxq8YF4xqlgD8jFYX7gx zPgw== MIME-Version: 1.0 Received: by 10.60.20.1 with SMTP id j1mr18319116oee.46.1353568758730; Wed, 21 Nov 2012 23:19:18 -0800 (PST) Received: by 10.60.64.170 with HTTP; Wed, 21 Nov 2012 23:19:18 -0800 (PST) In-Reply-To: <83a9uauwwo.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> Date: Thu, 22 Nov 2012 08:19:18 +0100 Message-ID: Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) > 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. > 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. The only problem I've observed when doing it is the one explained in this thread, and I'd like to fix it. 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. -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 22 12:07:53 2012 Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 17:07:53 +0000 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 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 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) 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) Date: Thu, 22 Nov 2012 19:05:43 +0200 From: Eli Zaretskii Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <83zk29tvo8.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4976] > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 22 14:17:44 2012 Received: (at 12955) by debbugs.gnu.org; 22 Nov 2012 19:17:44 +0000 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 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 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== MIME-Version: 1.0 Received: by 10.182.21.142 with SMTP id v14mr1114564obe.46.1353611778353; Thu, 22 Nov 2012 11:16:18 -0800 (PST) Received: by 10.60.64.170 with HTTP; Thu, 22 Nov 2012 11:16:18 -0800 (PST) In-Reply-To: <83zk29tvo8.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> <83zk29tvo8.fsf@gnu.org> Date: Thu, 22 Nov 2012 20:16:18 +0100 Message-ID: Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 23 03:54:58 2012 Received: (at 12955) by debbugs.gnu.org; 23 Nov 2012 08:54:58 +0000 Received: from localhost ([127.0.0.1]:34054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tbp2E-0005uf-PX for submit@debbugs.gnu.org; Fri, 23 Nov 2012 03:54:58 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:55223) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tbp2A-0005uV-7m for 12955@debbugs.gnu.org; Fri, 23 Nov 2012 03:54:54 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MDX00A00N0X1H00@a-mtaout21.012.net.il> for 12955@debbugs.gnu.org; Fri, 23 Nov 2012 10:53:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDX009Y4NCYW570@a-mtaout21.012.net.il>; Fri, 23 Nov 2012 10:53:23 +0200 (IST) Date: Fri, 23 Nov 2012 10:53:24 +0200 From: Eli Zaretskii Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <83r4nku2d7.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> <83zk29tvo8.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 22 Nov 2012 20:16:18 +0100 > From: Dani Moncayo > Cc: 12955@debbugs.gnu.org > > > 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). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 22 Nov 2012 20:16:18 +0100 > From: Dani Moncayo > Cc: 12955@debbugs.gnu.org > > > 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). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > Date: Thu, 22 Nov 2012 20:16:18 +0100 > From: Dani Moncayo > Cc: 12955@debbugs.gnu.org > > > 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). The SH part is not for MSYS. It's for Cygwin Bash. It also worked with the old port of zsh, which I used for some time. > 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). Installing the GnuWin32 port of Coreutils is equally easy. > > 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). I committed a variant of that in trunk revision 110989. Please test. > > 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 for the offer. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 23 14:57:19 2012 Received: (at 12955-done) by debbugs.gnu.org; 23 Nov 2012 19:57:19 +0000 Received: from localhost ([127.0.0.1]:35238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbzNG-0001Tf-Hr for submit@debbugs.gnu.org; Fri, 23 Nov 2012 14:57:19 -0500 Received: from mail-oa0-f44.google.com ([209.85.219.44]:65186) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbzNE-0001TY-J5 for 12955-done@debbugs.gnu.org; Fri, 23 Nov 2012 14:57:17 -0500 Received: by mail-oa0-f44.google.com with SMTP id n5so8741422oag.3 for <12955-done@debbugs.gnu.org>; Fri, 23 Nov 2012 11:55:47 -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=FM24NVrPOrxSFWN6uz2wlqSLzxMwuOkWRO3k9vbgXEw=; b=R8HhyTrnVOxKzCw2JE3+7cH2XtfhgEJJorRx0Rav7YcsgPY/ns9FQyti7Pb+1/vKBZ cKSUZVXWPPKkN9xJ1ypRUKKltUUmF/p62CgK0qNlcJfUyt5fRW6YjFU/uQ1cfg6PLIwT Awww5j1F7Nuq/lnuEtykgF45yYZ1n4Ph0N87pRcQ4nSSCe9KWgl7U1MpKPC7Bt0KLxsJ IJb7pEmao0Rshjqwit/UYEtIasAzlshnb8YtBhE+pTMkrN1Wl2iD18pjilZFBg6/6mVI UOErg3JosShzpuqWcQnAVYO5W8HI6Yj1EDYvPW26sx1ZRcrSXF0ct4cJh+r43mHTwG8D ikzA== MIME-Version: 1.0 Received: by 10.182.21.142 with SMTP id v14mr3740417obe.46.1353700547253; Fri, 23 Nov 2012 11:55:47 -0800 (PST) Received: by 10.60.64.170 with HTTP; Fri, 23 Nov 2012 11:55:47 -0800 (PST) In-Reply-To: <83r4nku2d7.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> <83zk29tvo8.fsf@gnu.org> <83r4nku2d7.fsf@gnu.org> Date: Fri, 23 Nov 2012 20:55:47 +0100 Message-ID: Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12955-done Cc: 12955-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) >> Yes that seems to work for me. I've tested both cases (SH and CMD). > > I committed a variant of that in trunk revision 110989. Please test. I've tried to invoke mingw32-make with and without MSYS' bash on PATH, and it works for me in both scenarios. Therefore, let's close this bug report. Thank you so much. PS: The build now goes fine for my use-case, i.e., when I run mingw32-make from a cmd.exe shell, having the MSYS bash is on PATH. But out of curiosity, I've just tried to invoke mingw32-make right the MSYS bash shell, and in this second case a child cmd.exe shell is soon started and waiting for input. (Just for the record) -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 23 16:44:51 2012 Received: (at 12955) by debbugs.gnu.org; 23 Nov 2012 21:44:51 +0000 Received: from localhost ([127.0.0.1]:35315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tc13K-0003vm-TA for submit@debbugs.gnu.org; Fri, 23 Nov 2012 16:44:51 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:62476) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tc13H-0003vb-8u for 12955@debbugs.gnu.org; Fri, 23 Nov 2012 16:44:48 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDY00600MXQTB00@a-mtaout20.012.net.il> for 12955@debbugs.gnu.org; Fri, 23 Nov 2012 23:43:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDY006Y8N05NJ40@a-mtaout20.012.net.il>; Fri, 23 Nov 2012 23:43:17 +0200 (IST) Date: Fri, 23 Nov 2012 23:43:20 +0200 From: Eli Zaretskii Subject: Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <838v9st2pz.fsf@gnu.org> References: <83a9uauwwo.fsf@gnu.org> <83zk29tvo8.fsf@gnu.org> <83r4nku2d7.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 23 Nov 2012 20:55:47 +0100 > From: Dani Moncayo > Cc: 12955-done@debbugs.gnu.org > > But out of curiosity, I've just tried to invoke mingw32-make right the > MSYS bash shell, and in this second case a child cmd.exe shell is soon > started and waiting for input. (Just for the record) [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4655] X-Debbugs-Envelope-To: 12955 Cc: 12955@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Fri, 23 Nov 2012 20:55:47 +0100 > From: Dani Moncayo > Cc: 12955-done@debbugs.gnu.org > > But out of curiosity, I've just tried to invoke mingw32-make right the > MSYS bash shell, and in this second case a child cmd.exe shell is soon > started and waiting for input. (Just for the record) Maybe MSYSTEM is not in the environment in that case, because MSYS removes it when it calls non-MSYS programs (in this case, mingw32-make). From unknown Sat Jun 21 03:22:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 22 Dec 2012 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator