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

Alexis flexibeast at gmail.com
Fri Jun 21 11:15:29 AEST 2024


Bakul Shah <bakul at iitbombay.org> writes:

> But the overlap between two different programs or their 
> assumptions
> will be
> only partial (except for some very basic things) which likely 
> means
> the cache
> won't quite work. For example, you may find that program A and B
> depend on different versions of some library C.

The basic things are, in fact, a significant part of what autoconf 
is being used to check for. "Does this platform provide this 
function?" And that doesn't significantly change between versions 
of the specific libc used by the system (glibc, musl, the *BSD 
libcs, etc.); due to their nature as a fundamental part of the 
system, they're relatively conservative (compared to higher-level 
libraries and applications) as to the rate at which they change, 
and what they add and remove. i've only rarely encountered libc 
version issues when compiling many pieces of software for my use 
over the years.

For higher-level libraries, there's pkg-config and its 
reimplementations, such as pkgconf:

> pkgconf is a program which helps to configure compiler and 
> linker flags for development libraries.  This allows build 
> systems to detect other dependencies and use them with the 
> system toolchain.
-- pkgconf(1), https://www.mankier.com/1/pkgconf

which can (and does) get _used_ by autoconf, but is a standalone 
project. (Which is not to say i'm endorsing the system, just that 
it exists, and is independent of the autoconf system.)

> And how does the
> configure or whatever
> tool find out that no dependency has changed? I don't think you 
> can
> factor
> out a cache of such data to a global place that will work for 
> every
> ported
> program.

You're right: not for _every_ ported program. But even if the 
cache worked for _most_, and simplified the build processes of 
_most_ programs, thus reducing the complexity needing to be 
understood by build maintainers, and reducing the complexity 
available for malfeasants to hide backdoors, that would still be a 
significant win, in my opinion. Don't let the perfect be the enemy 
of the good, etc.


Alexis.


More information about the TUHS mailing list