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

[Eli Zaretskii]

> Date: Thu, 22 Nov 2012 08:19:18 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 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.