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

["Alan D. Salewski" <ads@salewski.email>]

On Thu, Jun 20, 2024, at 21:43, segaloco via TUHS wrote:
> On Thursday, June 20th, 2024 at 6:15 PM, Alexis <flexibeast@gmail.com> wrote:
>
[...]

>> The basic things are, in fact, a significant part of what autoconf
>> is being used to check for. "Does this platform provide this
>> function?"
>>
>> ...
>> 
>> 
>> Alexis.
>
> This aspect of things I have found a bit perplexing.  On one hand, 
> sure, it's nice to have some scripted system spit out a:
>
> "Dependency xyz not found"
>
> But where it falls apart in my head is what that tells me that, for 
> instance, cpp's error diagnostic about a missing include or ld saying a 
> symbol or library wasn't found does.  It's in my mind a minor 
> convenience but one that doesn't justify all the machinery between 
> one's self and make just to provide.  Granted that's not all autotools 
> does, so a poor example in practice, but in theory gets at one of my 
> irks, packaging something that you are already going to discover some 
> other way.  That and "does my target platform list support xyz" isn't 
> necessarily a matter I'd wait until I've created a whole build package 
> around my software to settle...
>
> Just a small part of the puzzle but one of the parts that gives me more 
> headaches than not.  Now I don't get to respond to a compiler or linker 
> asking for something by putting it where it asked for it, now I also 
> have to figure out how to do the extra work to ensure that it's put 
> somewhere and in a way that all this machinery between myself and the 
> compiler can also verify in its own magical way component <xyz> is 
> present.
[...]

The thing about the autotools is that there are two different
audiences for different aspects of the system: consumers of the
package (sysadmins, porters, distro packagers...) and developers. In
general, the developers need to work a little harder to make life of
the consumers easier. While some consumers might be fine with (to
use the example above) a cpp error diagnostic about a missing
include, I imagine most would prefer a "configure time" diagnostic
explaining that dependency package foo needs to be installed before
they try to build it. Those who are not C or C++ developers wouldn't
necessarily know what cpp is, or how to control it.[0]

I, for one, appreciate that pretty much any build tool can be
integrated into the autotools framework, in part because it acts as
a barrier between the consumers and the underlying language-specific
build tooling, etc. The same could be (and has been) said of portable
Makefiles, but the level of effort would be quite high to achieve
what the autotools-generated Makefiles produce out of the box. E.g.,
the 'make distcheck' target not only drives a full configure and
build in a temporary directory, but also verifies that a VPATH build
(building separately from the source tree) works.

Language-specific build mechanisms are fine as far as it goes. But
the more of them you encounter and need to interact with directly,
the more friction there is. The audience for such tools is primarily
the developer. Python's pip, JavaScript's npm (or yarn, or ...),
golang, Rust's cargo, Java's mvn (or ant, or ivy, or ...), Clojure's
lein, Perl's ExtUtils::MakeMaker (or Module::Build, or ...), Ruby's
gem, ... And tooling to produce documentation is even worse:
DocBook, AsciiDoc, reStructuredText. Even driving LaTeX has become
complicated (PDFLaTeX, XeTeX, LuaTeX, ...). The developer who
necessarily understands such things can, with some effort, integrate
them into an autotools build, making life much easier for the
consumers of the package (assuming the integration has been done
well).

When the audience or consumer of the package is sysadmins (including
end-users acting as their own sysadmin), porters, and distro
packagers, I think "the usual dance" of "./configure && make" is
nice because it is consistent across underlying languages,
compilers, and whatever auxiliary tools are needed to produce
documentation, etc.

And I happen to like m4  :-)
*ducks*

-Al


[0] Sadly, the days when C was the lingua franca amongst programmers
    seem to be behind us.

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski