Subject: Re: bug#10665: 24.0.93; Building for MS Windows using MinGW encounters a build problem in ../emacs-24.0.93/src/makefile

From: Eli Zaretskii <[email-masked]>
Date: Mon, 30 Jan 2012 23:34:17 +0200

> From: "Gallagher, Kevin" <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Date: Mon, 30 Jan 2012 14:58:37 -0600
> 
> I did some further investigation and the problem is definitely NOT with the MSYS bash. When I build from a Windows command line, I see the exact same symptom.  It turns out that the actual problem is with the MSYS GNU make.  If, instead, I use the MinGW GNU make executable, called mingw32-make.exe, the problem disappears.  (The MSYS GNU make is version 3.81 while the MinGW version is 3.82.)

It's not the version of Make that matters (I've built Emacs with a
MinGW Make 3.81 many times), it's probably the way the MSYS Make tries
to convert arguments that start with a slash to Windows style file
names (/d/foo/bar -> d:/foo/bar).  Except that /c is not a file
name...

> By the way, the nt/INSTALL file is very out-of-date with its disparaging remarks toward the MSYS port of bash.  The latest version is really quite good. I have used it extensively for quite some time without any issues.

If you tell which version is working well, I can update nt/INSTALL.

However, in general, it doesn't make much sense to use MSYS tools
(_any_ MSYS tools) for building a native Windows port of Emacs.  MSYS
is for configuring and building software originated on Unix and GNU
systems using Posix configury and scripts.  The native Windows build
of Emacs does not use Posix machinery, it uses Windows batch files and
Makefile's that don't require a Posix shell.  So you are really using
MSYS outside of its intended purpose.  I don't recommend that, even
though I successfully use MSYS to configure and build other packages,
which don't have Windows-specific build procedures.

> Finally, my previous concern about the rule for the target globals.h in the ../emacs-24.0.93/src/makefile:
> 
>   globals.h: gl-stamp
>         @cmd /c rem true
> 
> seems to be still valid.  What is the point of a rule explicitly invoking the Windows command interpreter and passing it ONLY a comment line? 

How else can you have a command that does nothing?  The Posix
equivalent is

   globals.h: gl-stamp; @true