Re: emacs-win-builder

[Eli Zaretskii <eliz@gnu.org>]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 1 Sep 2016 15:39:42 +0300
> 
>  E.g., on my systems, MSYS can only work when invoked from the MSYS Bash
>  window.
> 
> That's interesting. What's the possible breaking point here? Assuming that we clear our exec-path, use
> bash.exe from msys directory and add whatever necessary to the process environment, I could not think of
> anything that should break here, that's not easily fixable.

Mainly, PATH (in process-environment) vs exec-path, which is
exacerbated by MSYS remapping of /usr etc. to Windows directory
structure.  I think you worked around that for the case that MinGW and
MSYS are installed as part of your script, but you cannot possibly do
that reliably for a system where both are already installed.  E.g., on
my system, MSYS and MinGW are in two separate trees, side by side, and
there's no easy way for you to know how MSYS /usr/bin is remapped to
its Windows name.

> For libarchive we would need some way to extract zip files
> first. GnuWin provides a setup version of unzip, so I guess that
> would be one option.

Doesn't w32-shell-execute work?  The Explorer can unzip archives, so
perhaps this could be an alternative, if it works.

> First, what would be some reasonable optimization profiles. I think we all agree that we want to have
> something with debug information as default. So what would be the best flags here? And then there should be
> an option to make an optimized build, what would be the best flags for it?

I use "-O0 -gdwarf-2 -g3" for debug builds, and "-O2 -gdwarf-2 -g3"
(or even -gdwarf-4 for GCC 5 and later) for optimized builds.  GNU
projects normally do "make install-strip" for the official releases
and "make install" for pretests and snapshots, so my advice would be
to do that here as well.

> Also I do
> "--enable-checking='yes,glyphs' --enable-check-lisp-object-type"
> everywhere.

It's a good idea in pretests and snapshots, but I think you should
remove it for official releases. They just make Emacs slower, which is
not a good thing in production.

> Also, are there any other configure related options we may want to implement?

The --with-modules switch comes to mind, but that's all.  For 32-bit
builds, I'd also recommend --with-wide-int, but I know some people
disagree.