Building Emacs on MSYS2 (was: Build failure for Emacs master)

Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> In MSYS2 and other OS there are *-git packages just to have the last 
>> development source not because that people aims to develop and maintain 
>> the applications of those packages..
>
> I'd urge all those who are tracking development sources to please use
> the official established build procedure.  Using 3rd-party packages
> whose procedures deviate from the project instructions is susceptible
> to bumping into problems that stem from using those deviant
> procedures, which is an added maintenance burden I think we'd like to
> avoid.  Also, doing so means less testing for the official build
> procedures.

Currently this is the code for configuring the build of emacs-git on
MSYS2 MinGW-packages:

build() {
  [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf "${srcdir}/build-${MINGW_CHOST}"
  mkdir -p "${srcdir}/build-${MINGW_CHOST}"
  cd "build-${MINGW_CHOST}"

  local with_wide_int='no'

  if test "${CARCH}" == 'x86_64'; then
    with_wide_int='yes'
  fi

  CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
  CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
  LDFLAGS="-s -Wl,-s"
  "${srcdir}/${_realname}/configure" \
    --prefix="${MINGW_PREFIX}" \
    --build="${MINGW_CHOST}" \
    --with-wide-int="${with_wide_int}" \
    --with-sound="yes" \
    --with-file-notification="yes" \
    --without-gpm \
    --without-gconf \
    --without-gsettings \
    --without-selinux

  make
}

Apart from setting with_wide_int and adding some (unnecessary, IMHO)
optimization options, it looks like a fairly standard configuration.

The package contains two patches too. This one that looks like trying to
avoid a link problem:


--- src/image.c.orig	2014-10-15 14:18:29.088716000 +0200
+++ src/image.c	2014-10-15 15:54:12.407522800 +0200
@@ -7862,7 +7862,7 @@
   };
 
 #if defined HAVE_NTGUI && defined WINDOWSNT
-static bool init_imagemagick_functions (void);
+#define init_imagemagick_functions NULL
 #else
 #define init_imagemagick_functions NULL
 #endif



and this one that seems related to locating the source directory:

--- src/lread.c.orig	2014-11-04 20:29:22.129549000 +0100
+++ src/lread.c	2014-11-04 22:33:07.346414100 +0100
@@ -4351,6 +4351,12 @@
             } /* Vinstallation_directory != Vsource_directory */
 
         } /* if Vinstallation_directory */
+      else
+        {
+          Vsource_directory
+            = Fexpand_file_name (build_string ("../"),
+                                 Fcar (decode_env_path (0, PATH_DATA, 0)));
+        }
     }
   else                          /* !initialized */
     {


> If you can convince the MSYS2 maintainers to adopt the official build
> procedure, it would be even better.

I can change the emacs-git package for not adding those optimization
options and not setting with-wide-int. Do you think that's enough?

> Failing that, please consider
> switching back to what the project recommends, what is documented in
> the relevant INSTALL documents.

Because MSYS2 does not distribute binaries for emacs-git, I guess that
the number of people who currently uses the PKGBUILD shown above is very
small. AFAIK Angelo and others that build Emacs on MSYS2 are not using
the PKGBUILD, but following the recipe on the Emacs' docs (possibly with
their own personal modifications.)

Re: Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 14 Apr 2016 17:58:09 +0200
> 
> Currently this is the code for configuring the build of emacs-git on
> MSYS2 MinGW-packages:
> 
> build() {
>   [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf "${srcdir}/build-${MINGW_CHOST}"
>   mkdir -p "${srcdir}/build-${MINGW_CHOST}"
>   cd "build-${MINGW_CHOST}"
> 
>   local with_wide_int='no'
> 
>   if test "${CARCH}" == 'x86_64'; then
>     with_wide_int='yes'
>   fi
> 
>   CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
>   CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
>   LDFLAGS="-s -Wl,-s"
>   "${srcdir}/${_realname}/configure" \
>     --prefix="${MINGW_PREFIX}" \
>     --build="${MINGW_CHOST}" \
>     --with-wide-int="${with_wide_int}" \
>     --with-sound="yes" \
>     --with-file-notification="yes" \
>     --without-gpm \
>     --without-gconf \
>     --without-gsettings \
>     --without-selinux
> 
>   make
> }
> 
> Apart from setting with_wide_int and adding some (unnecessary, IMHO)
> optimization options, it looks like a fairly standard configuration.

Actually, I see nothing standard at all here.  I see no reason for
_any_ of the options, neither in CPPFLAGS nor in CFLAGS.  They are all
potential source of trouble for the uninitiated.  (If there are real
reasons for them, they must be bugs that should be reported and fixed
upstream.)  And why "-s" in LDFLAGS? that's just hostile to
developers, since no user can possibly provide any details about any
bugs.  (Of course, this is in line with -fomit-frame-pointer, which is
also a killer for any attempts to debug.)  And all the switches to
'configure', with the single exception of --prefix (assuming that it
has the correct /d/foo/bar form and points to the MinGW directory, not
to MSYS2 directory) are simply clutter, they are no-ops at best and
potential trouble at worst.

Bottom line, I really don't like this script.

> The package contains two patches too. This one that looks like trying to
> avoid a link problem:
> 
> 
> --- src/image.c.orig	2014-10-15 14:18:29.088716000 +0200
> +++ src/image.c	2014-10-15 15:54:12.407522800 +0200
> @@ -7862,7 +7862,7 @@
>    };
>  
>  #if defined HAVE_NTGUI && defined WINDOWSNT
> -static bool init_imagemagick_functions (void);
> +#define init_imagemagick_functions NULL
>  #else
>  #define init_imagemagick_functions NULL
>  #endif

What link problem is that?  Why those who use the official procedure
never have or report it?

> and this one that seems related to locating the source directory:
> 
> --- src/lread.c.orig	2014-11-04 20:29:22.129549000 +0100
> +++ src/lread.c	2014-11-04 22:33:07.346414100 +0100
> @@ -4351,6 +4351,12 @@
>              } /* Vinstallation_directory != Vsource_directory */
>  
>          } /* if Vinstallation_directory */
> +      else
> +        {
> +          Vsource_directory
> +            = Fexpand_file_name (build_string ("../"),
> +                                 Fcar (decode_env_path (0, PATH_DATA, 0)));
> +        }
>      }
>    else                          /* !initialized */
>      {

What problem does this try to fix, and why?

> I can change the emacs-git package for not adding those optimization
> options and not setting with-wide-int. Do you think that's enough?

I think this should simply invoke the commands shown in
nt/INSTALL.W64, and that's it.  IOW, it should run the official
procedure, and if there are reasons to change that, those reasons
should be reported and discussed.

> > Failing that, please consider
> > switching back to what the project recommends, what is documented in
> > the relevant INSTALL documents.
> 
> Because MSYS2 does not distribute binaries for emacs-git, I guess that
> the number of people who currently uses the PKGBUILD shown above is very
> small.

I have similar issues with the MSYS2 procedure for building official
releases.

Thanks.

Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Angelo Graziosi]

Ciao Óscar,

Óscar Fuentes wrote:
> AFAIK Angelo and others that build Emacs on MSYS2 are not using
> the PKGBUILD, but following the recipe on the Emacs' docs (possibly with
> their own personal modifications.)

really, I DO build Emacs on MSYS2 with that _PKGBUILD_ [*]. It is on 
GNU/Linux and on OSX which I use some other recipe (my build scripts..)

Regarding the image.c.diff and lread.c.diff patches...

If I remember correctly, when the mingw*imagemagick port is installed, 
'configure' tries to "build" using the imagemagick support and the build 
fails if those patches are not applied.. Maybe the patches fix the build 
with imagemagick support. But is it a real support or only a workaround 
so that the build is completed, apparently adding the support for 
imagemagick?

I have this doubt..


Ciao,
  Angelo.

---
[*] Oops.. with my modification:

$ cat mingw-w64-emacs-git/PKGBUILD
[...]

## USAGE EXAMPLES:
##
##  MAKE_OPT='-j3' MINGW_INSTALLS=mingw64 makepkg-mingw -sLf
##

: ${MAKE_OPT=}

[...]

prepare() {
   cd "${_realname}"
   patch --binary --forward -p0 < "${srcdir}/image.c.diff"
   patch --binary --forward -p0 < "${srcdir}/lread.c.diff"
   ./autogen.sh all
}

build() {
   [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf 
"${srcdir}/build-${MINGW_CHOST}"
   mkdir -p "${srcdir}/build-${MINGW_CHOST}"
   cd "build-${MINGW_CHOST}"

   local with_wide_int='no'

   if test "${CARCH}" == 'x86_64'; then
     with_wide_int='yes'
   fi

   CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
   CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
   LDFLAGS="-s -Wl,-s"
   "${srcdir}/${_realname}/configure" \
     --prefix="${MINGW_PREFIX}" \
     --build="${MINGW_CHOST}" \
     --enable-gcc-warnings=no \
     --with-wide-int="${with_wide_int}" \
     --with-sound="yes" \
     --with-file-notification="yes" \
     --without-gpm \
     --without-gconf \
     --without-gsettings \
     --without-selinux

   echo
   echo "Using MAKE_OPT = ${MAKE_OPT}"
   echo

   make ${MAKE_OPT}
}

[...]

Re: Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Thu, 14 Apr 2016 21:56:11 +0200
> 
> If I remember correctly, when the mingw*imagemagick port is installed, 
> 'configure' tries to "build" using the imagemagick support and the build 
> fails if those patches are not applied..

Then you should give the --without-imagemagick switch to configure.