[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: |
Eli Zaretskii |
Subject: |
bug#12955: 24.3.50; Build process on MS-Windows: sometimes needs "human intervention" |
Date: |
Fri, 23 Nov 2012 10:53:24 +0200 |
> Date: Thu, 22 Nov 2012 20:16:18 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12955@debbugs.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).
The SH part is not for MSYS. It's for Cygwin Bash. It also worked
with the old port of zsh, which I used for some time.
> 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).
Installing the GnuWin32 port of Coreutils is equally easy.
> > 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).
I committed a variant of that in trunk revision 110989. Please test.
> > 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 for the offer.