21 Jun
2024
21 Jun
'24
7:44 a.m.
On Thu, Jun 20, 2024 at 6:22 PM Greg A. Woods <woods(a)robohack.ca> wrote:
At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast(a)gmail.com> wrote:
Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less
Unix philosophy' The Register
Warner sufficiently summed up the philosophical reason for the
probe-the-world-after-slumber approach. It seems foolish at first; a
waste of time/cycles; but the deeper you dig into the problem space
the less foolish it becomes. As an example, autoconf builds easily
handle cross toolchains or shimmed toolchains where a mix of native
and emulated tools are used to speed up cross builds.
I agree with the chorus that the implementation of autoconf is awful.
But the audience that assume that autoconf is also bad, and the bits
and bobs of shell and make are somehow equivalent, is living in a
state of willful ignorance.
So,
to what extent is the complexity of
autoconf _needed_ nowadays?
For xz in particular Autoconf is _probably_ not necessary, but I haven't
examined it in detail.
For a vast amount of application C code and libraries no build-time
configuration beyond what's provided by the system headers and the C
compiler is necessary. This is especially true if the code is designed
to require a slightly "modern" version of C, such as iso9899:1999
(perhaps with GNU CC extensions).
There are however some things in more systems level programs and
libraries that are more difficult to handle even with well written code,
but compared to the number of tests offered by the likes of Autoconf,
well those things are actually very few. One thing that Autoconf gets used for, but for which
it is not really
necessary, is for choosing build-time options. Indeed its feature set
for doing so is complex and error-prone to use! Too much weird mixing
of shell scripts and M4 macros, with all the quoting nightmare this
brings. Just try to read XZ's configure.ac! A simple declarative
configuration file, such as a Makefile fragment, is sufficient.
When you wander into the realm of non-C code things might also be a bit
more complex, unless of course it's Go code, where this problem simply
doesn't exist in the first place.
Go's approach was the same as Java, if you control the level of
abstraction sufficiently you eliminate much of the complexity.
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>