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

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> 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.