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

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

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

Okay.

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

Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit
the only allowed trespasser, for obvious reasons.)

I'm not saying that I'll stop building Emacs the day MSYS becomes a
requirement, but you'll admit that it is a heavy, potentially
problematic one.

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

I'm not saying that it would be trivial. And some MinGW-specific
tinkering would be necessary, yes. But for the user it would be
hassle-free (well, CMake with the "MinGW Makefiles" generator doesn't
want a `sh.exe' on your PATH, but it explicitly tells you so when you
start the build.)

> 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'm not inclined to adding responsibilites to the users for the
(understandable) convenience of the developers, if other options exists.
Rather I'll prefer a system that is easy enough to maintain so the
hassle becomes less serious. And then, if the system is cross-platform
and there are developers who enjoy using it for their hacking, you'll
get some help for free.

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

Yes, sorry.

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

One such thing is easily abstractable (sp?) on CMake: "run this platform
check unless this or that condition holds, for which the answer is
that."

The declarative/procedural nature of CMake makes so much things trivial
to implement compared against autotools/automake.