Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Tue, 26 Mar 2013 12:10:22 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> Just for the record: this problem does not exist in the GNU/Linux build
> >> procedure.  More specifically, in the Unix makefiles, "make bootstrap"
> >> kind of like "make clean; make".  So presumably, by suitably changing
> >> the Windows makefiles to mimick what the Unix makefiles do, we should be
> >> able to get the same behavior.
> >
> > Can't be done without a lot of non-trivial hacking, if at all
> > possible.  The Unix makefiles use Borne shell features to get this
> > done, and I don't want to require Windows users to have a native
> > Windows port of a Unixy shell installed (because there are no good
> > ones).
> >
> > That said, feel free to donate patches to make this happen.
> >
> >> Of course, making it possible to build the Windows version via
> >> ./configure would also solve it.
> >
> > In the works, but I could use some help.  The main problem, which I'm
> > still unsure what is the best way of solving, is how to tell configure
> > not to test for certain features and instead accept that the test
> > should succeed (because those features are implemented in Emacs
> > sources).
> 
> It seems to me that your two paragraphs contradict: on the first you say
> that you don't want a Bourne shell on Windows, but in the second you say
> that you are working on running the ./configure script on Windows (which
> maybe does not require a Bourne shell, but some kind on Unix shell
> anyway.)

There's no contradiction.  These are 2 different situations involved
here: the first one where Windows-specific makefiles are used with
native Windows tools, the second one where Unix makefiles are used
with tools that can produce and grok them.

> What new requirements would add running ./configure on Windows, as per
> your plan?

MSYS and the auxiliary MSYS tools will have to be installed on the
end-user system.

> Instead on trying to force a square peg into a round hole, why not using
> something native to Windows such as CMake, which adds a single, well
> defined dependency to the build, and allows proper platform checks,
> scriptability, etc.?

I've used CMake in a package much less complex than Emacs (Gawk, if
you want to know), and my conclusion was that it also requires some
non-trivial amount of tinkering, in order to work well with the MinGW
development environment.  And that tinkering needs good knowledge of
CMake, something not easily gleaned from the available docs.  So I see
no significant advantage going that way, unless mainline Emacs
development switches to CMake.

By contrast, using the Posix configure script and Posix Makefile.in
files will relieve us from at least one of the duties: the need to
track mainline development in a separate set of scripts that no one of
the head maintainers understands well, or wants to.  That is a huge
gain, which might just countermand the disadvantage of asking users to
install MSYS.

> I know that this proposal was rejected twice before, but I'll bet that
> making ./configure work on Windows would require less work than a
> complete CMake build specification for Emacs.

I guess you meant "less work" for CMake, not for ./configure.

However, my experience does not support your bet.  Running the current
configure script with MSYS tools is actually a no-brainer: I already
tried that, and it worked out of the box with no need to change
anything.

The only issue is what I mentioned above: that the configure script
probes the development environment, where many features are missing,
features that were implemented in the Emacs sources instead.

There's an easy way of forcing the configure script to pass tests
without trying (set the corresponding ac_* variables before running
the script).  But what I'd like to do is to maintain a text file with
a list of functions, header files, and other features that are
implemented in Emacs's own sources, and provide an automated way to
set those autoconf variables from that list.  This way, whenever a new
feature is added, all that will be need is to add a few lines to the
list.

Or maybe there's an easier/more elegant method of skipping autoconf
tests with known results.  I'm all ears.