bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention"

[Dani Moncayo]

> 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