21 Jun
2024
21 Jun
'24
7:15 a.m.
Bakul Shah <bakul(a)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.