Re: Building Emacs on MSYS2

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Thu, 14 Apr 2016 18:43:08 +0200
> 
> Eli Zaretskii <address@hidden> 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.

We are talking about building the development snapshots.  It is IMO
silly to build those without debugging info.

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

Development snapshots are best compiled with debugging info (and with
"--enable-checking" as well, btw).

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

I wonder why someone might think that copying configure-time option
from a totally different OS could be a good idea.  Why not ask here
instead?

> OTOH is a good practice to explicitly state "I have this feature so use
> it".

Emacs can do that without these switches, see
system-configuration-features.

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

None of them are related to this, actually.

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

This kind of problem (if it indeed is it) should be fixed in
site-init.el files, not by patching sources.

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

That's not what I meant, I meant the argument about the small number
of people who use this script.  I don't think it's small, because the
same problems are in building the official releases.