Re: Building Emacs on MSYS2

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.)

The MSYS2 packages (as well as the Arch Linux packages which serves as
models) are intended for use on production, not for debugging.

OTOH, PKGBUILDs are supposed to have code for choosing debug builds if
the user passes certain flags to the build tool. This specific PKGBUILD
lacks that code. Adding it is not difficult.

> 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)

Of course, the MinGW hierarchy is used.

> are simply clutter, they are no-ops at best and
> potential trouble at worst.

I guess those came from the Arch Linux package that served as model.

OTOH is a good practice to explicitly state "I have this feature so use
it". The MSYS2 build procedure already makes sure that the dependencies
are installed, so if something is not properly detected by the configure
script, it is a good thing to error out. Most of the listed options on
that PKGBUILD are not related to this, though.

> 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?

I have no idea. Probably imagemagick, as built and distributed by MSYS2,
does not have or need that feature.

>> 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?

Just guessing: the post-build install directory is not the same as the
directory used for running Emacs (after running `make install', the
resulting files are packaged, stored and distributed by the project;
then users unpackage in their own installs; it's like doing `make
install' and the moving the install directory elsewhere.)

>> 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.

Some modifications may be unavoidable due to how MSYS2 works (see above)
but I agree with the sentiment.

>> > 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.

The idea is to put emacs-git on good shape and, when emacs 25 is
released, port the modifications to the stable MSYS emacs PKGBUILD.