From: Dani Moncayo <dmoncayo@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 12955@debbugs.gnu.org
Subject: bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention"
Date: Thu, 22 Nov 2012 20:16:18 +0100 [thread overview]
Message-ID: <CAH8Pv0h=VcNaM+ePcWAiAVEkVYabq6+zjQEts88nPSoC14SjoQ@mail.gmail.com> (raw)
In-Reply-To: <83zk29tvo8.fsf@gnu.org>
> 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
next prev parent reply other threads:[~2012-11-22 19:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 20:49 bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" Dani Moncayo
2012-11-21 22:43 ` Dani Moncayo
2012-11-22 3:41 ` Eli Zaretskii
2012-11-22 7:19 ` Dani Moncayo
2012-11-22 17:05 ` Eli Zaretskii
2012-11-22 19:16 ` Dani Moncayo [this message]
2012-11-23 8:53 ` Eli Zaretskii
2012-11-23 19:55 ` Dani Moncayo
2012-11-23 21:43 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH8Pv0h=VcNaM+ePcWAiAVEkVYabq6+zjQEts88nPSoC14SjoQ@mail.gmail.com' \
--to=dmoncayo@gmail.com \
--cc=12955@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.