[TUHS] Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Kevin Bowling]

On Thu, Jun 20, 2024 at 6:22 PM Greg A. Woods <woods at robohack.ca> wrote:
>
> At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast at gmail.com> wrote:
> Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> >
> > 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.

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.

> 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 at acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
> Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>