bug#18302: MSYS2 build issues

[Eli Zaretskii]

> Date: Wed, 20 Aug 2014 11:54:53 +0200
> From: Karol Ostrovsky <karol.ostrovsky@gmail.com>
> Cc: Chris Zheng <chriszheng99@gmail.com>
> 
> thanks to the work of Chris Zheng and Eli Zaretskii we can build Emacs
> on MSYS2 with MinGW-w64.  However, the process is not completely
> painless: xpm support needs manual tweaking of CFLAGS, configure
> script must be run with special flags, and make sometimes crashes for
> the "emacs$(EXEEXT)" target.

What do you mean by "make crashes"?  Can you show some messages or
other evidence of these crashes?

> I am submitting my proposed fixes for these three issues (based on the
> latest trunk version of Emacs).  With this fix I can successfully
> compile 64-bit Emacs using MSYS2 and MinGW-w64 with automatic xpm
> support, and the process follows the same easy steps as described in
> nt/INSTALL (just running ./autogen.sh, ./configure --prefix=..., and
> make).  I intend to submit some additional MSYS2+MinGW-w64
> documentation (file nt/INSTALL) should this patch be accepted.

Thanks.

First, I don't see your name on file with the FSF copyright
assignments.  Without that, we will be unable to accept substantial
contributions such as this one.  Would you be willing to sign the
necessary legal papers (assuming you are the sole author of these
changes)?

I have a few questions/comments about your suggested changes.  (In the
future, please always send diffs obtained by "bzr diff" or "diff -u",
not entire files.)

> -      *-mingw32 )
> -             opsys=mingw32
> +      *-mingw* )
> +             opsys=mingw

This change from "mingw32" to "mingw" causes a lot of changes all
over.  is it really necessary?  Is there a problem to call the system
"mingw32"?  It's just a value of a variable, with no other meaning.

Without changing "mingw32" to "mingw", the changes are small enough to
not require legal papers (but you might need them anyway further down
the road, if you intend to submit more patches).

> -if test "$opsys" = "mingw32"; then
> -  case "$canonical" in
> -    x86_64-*-mingw32) C_SWITCH_SYSTEM="-mtune=generic" ;;
> -    *) C_SWITCH_SYSTEM="-mtune=pentium4" ;;
> -  esac
> +if test "$opsys" = "mingw"; then
> +  C_SWITCH_SYSTEM="-mtune=generic"

Why do you want to change the -mtune switch for the 32-bit build?  It
is by default configured to Pentium 4 so that the resulting binary
could run on Windows 9X, which we still support.  Users that want to
produce binaries tuned to more modern CPUs for their own consumption
can always do that by asking for custom CFLAGS.

>  ### slightly different requirements wrt image libraries (it doesn't
>  ### use -lXpm because it loads the xpm shared library dynamically at
>  ### run time).
> -if test "${opsys}" = "mingw32"; then
> +if test "${opsys}" = "mingw"; then
>    if test "${with_xpm}" != "no"; then
> +    CPPFLAGS="$CPPFLAGS -I/mingw64/include/noX"
>      AC_CHECK_HEADER(X11/xpm.h, HAVE_XPM=yes, HAVE_XPM=no, [

Why do you need to add this switch to CPPFLAGS?  Why cannot the XPM
header files be installed in the default include tree?

> @@ -435,8 +435,7 @@
>       else \
>         LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump || exit 1; \
>         test "X$(PAXCTL)" = X || $(PAXCTL) -zex emacs$(EXEEXT); \
> -       rm -f bootstrap-emacs$(EXEEXT); \
> -       ln emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
> +       ln -vf emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
>       fi

This is a general (not MinGW-specific) part of src/Makefile.in, so I'm
not sure we should be changing it.  In particular, I'm not sure
non-GNU 'ln' supports these 2 switches (and why do you need -v
anyway?).

Also, I don't understand why this solves anything.  If "rm -f" fails,
presumably because bootstrap-emacs.exe is still running, so will, or
might, "ln -f".  And the failure is not fatal: just type "make" again,
and it runs to completion.

Thanks again for working on this.