[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