[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alternative build systems

From: Óscar Fuentes
Subject: Re: Alternative build systems
Date: Wed, 24 Aug 2022 01:38:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> When I made the CMake build system for LLVM/Clang, it was about 1.5
>> orders of magnitude less verbose than the autoconf-based system for
>> feature parity.
> No one says you'd see anything like that with Emacs.  Emacs is not a
> compiler system.

Indeed, probably less reduction is expected on Emacs' case because its
build requirements are way simpler than Clang/LLVM (which is much more
than a compiler, BTW.)

Or not, because even small autotools-based projects are overly verbose
and daunting.

>> CMake has the advantage of being procedural (like an ordinary scripting
>> language) and declarative (like `make'). This makes possible to use a
>> high level of abstraction that helps a lot when dealing with complexity.
> Sorry, that's not my experience.  In the few cases where I needed to
> tweak a CMake build (admittedly, nowhere as complex as Clang), I found
> myself battling the same kind of stuff as with Autoconf: a huge
> library of macros, variables, and settings.  Moreover, quite a few of
> those are semi-documented in semi-comprehensible way.  The moment you
> step 1/2" outside of the "usual" stuff, you are on your own.

At least CMake and other modern build systems grants you a high degree
of freedom around how to organize your build specification. You can
write obfuscated code on any language, but some languages are more
convenient than others when a hacker makes the effort of writing easily
understandable code.

>> For the Gnulib question, I can't answer, I don't know what it involves.
>> A quick web search says that Gnulib is tightly tied with autoconf and
>> messages like this are a bit gloomy:
>> https://lists.gnu.org/archive/html/bug-gnulib/2019-08/msg00091.html
> I know, right?  This is just an example of the problems we'd need to
> deal with.  (Does CMake support Emacs Lisp compilation? does it know
> about *.elc and *.eln files? does it know about emacs.pdmp? does it
> know about installing programs like Emacs? etc. etc.)

Teaching all those things to CMake is trivial. Adding support for a
project that expects that you use their build system is another thing

reply via email to

[Prev in Thread] Current Thread [Next in Thread]