--- Begin Message ---
|
Subject: |
24.3.50; Build process on MS-Windows: sometimes needs "human intervention" |
|
Date: |
Wed, 21 Nov 2012 21:49:53 +0100 |
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 address@hidden
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" |
|
Date: |
Fri, 23 Nov 2012 20:55:47 +0100 |
>> 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
--- End Message ---