bug#18302: MSYS2 build issues

[Eli Zaretskii]

> Date: Thu, 21 Aug 2014 12:08:08 +0200
> From: Karol Ostrovsky <karol.ostrovsky@gmail.com>
> Cc: Glenn Morris <rgm@gnu.org>, Chris Zheng <chriszheng99@gmail.com>, 
> 18302@debbugs.gnu.org
> 
> 1. I am the sole author of these changes.  I have no issue with
> signing the required legal papers.  Please, let me know how to proceed
> with this.

Glenn, could you please send him the papers?

> 2. MSYS2 'uname' is indeed the main source of the problem.  My
> solution fixes that, and also renames opsys=mingw32 to opsys=mingw.
> This renaming is not strictly necessary, but I believe it is a good
> practice to name things as clearly as possible.  In this case, the
> name mingw32 seems too related to a 32-bit system, which it is not any
> more after my changes.

I see no reason to change "mingw32" into something else.  It's just a
string, and doesn't imply anything about the bit-ness of the build.
In fact, users who build Emacs will never see this string.  Besides,
MinGW64 tools can also be used to build a 32-bit Emacs.

So let's leave that part alone.

> 3. "-mtune" change: I don't see how Pentium4 optimisations are related
> to running Windows9X.  I know people still running Windows95 on
> Pentium III.

"-mtune=pentium4" does not mean that Pentium III is not supported.  It
just means the code is tuned better for Pentium 4.

Without this switch, newer versions of GCC will use -mtune=native,
which is certainly bad news for users of much older CPUs.

> Shouldn't the official Emacs build be as generic as possible?

Hard to answer that without knowing what you mean by "generic" in this
context.

Again, users who want to build Emacs only for themselves can always
specify -mtune=native at configure time.

> Perhaps one should even take away the whole -mtune part for MinGW.

See above: it is there for a reason.

Note that the 64-build already uses -mtune=generic, because it is free
from the need to support Windows 9X.

> 4. CPPFLAGS for XPM change follows the same pattern as cygwin.  Both
> cygwin and MSYS2 install the XPM library in an unusual place.  Since
> adding an include path for cygwin was already accepted, I did not see
> any issue with adding a similar solution for MSYS2.

IMO, it is a mistake in the Cygwin case as well.  These issues should
be resolved in the compiler installation, not in packages.  If the
user installs xpm (or any other library) she should either install its
headers and library files in the standard places, or configure the
compiler to look in the non-standard places (e.g., by setting
C_INCLUDE_PATH in the environment).  Otherwise, your build environment
is not really 100% functional.

I'd urge the Cygwin Emacs maintainers to revert that special case, but
that's their call.  For native Windows builds, I certainly object to
introducing this deviation.

> 5. I am sorry I was not aware of the ln flag issues.  The -v was only
> to see the result and it is completely unnecessary, while the -f was
> needed just as it was used for "rm -f" in the original.  The crash is
> quite random, and currently I am unable to reproduce it.  Yesterday it
> was relatively easy to reproduce, but today it is not happening.
> However, I remember that make stopped with something like: unable to
> build emacs.exe on line 603 of src/Makefile with reason "rm: cannot
> remove ‘bootstrap-emacs.exe’: Device or resource busy".  The crash
> happened even when running make without a j flag, that is non-parallel
> build.
> 
> The easy manual workaround is to just start make again, but then it is
> hard to add emacs to any automated build system (for example as an
> MSYS2 package).
> 
> Given how random this crash is it is hard to justify any change to the
> Makefile.in until I or someone else can find the root cause.

I think the root cause is obvious: Windows won't let you delete the
executable file of a running program.  So small timing issues can open
a small window of opportunity for this failure.

How about adding a loop there that attempts to delete the file up to 5
times, say, each time sleeping for 1 second after a failure?  If that
works, it will always succeed on the 1st attempt on Posix hosts, so it
is harmless there.