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

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Wed, 21 Nov 2012 20:52:01 UTC

Severity: normal

Found in version 24.3.50

Done: Dani Moncayo <dmoncayo <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 12955 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12955 <at> debbugs.gnu.org
Subject: Re: 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




This bug report was last modified 12 years and 181 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.