[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human
From: |
Dani Moncayo |
Subject: |
bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" |
Date: |
Thu, 22 Nov 2012 20:16:18 +0100 |
> 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