On Thu, Jun 20, 2024, 5:35 PM Alexis <flexibeast@gmail.com> wrote:

> Bakul Shah via TUHS <tuhs@tuhs.org> writes:
>
> > To build a set of objects you need to worry about at least the
> > following:
> > - build recipes for each of them (which may also depend on other
> > things)
> > - configuration parameters
> > - dealing with differences on each platform
> > - third party libraries & alternatives
> > - toolchains (& may be cross-platform builds)
> > - supporting/navigating different versions of the last 3 above
> >
> > You can't really precompute all this as there are far too many
> > combinations and they keep changing.
>
> Both the blog author (who is a long-time sysadmin with many 'war
> stories') and myself understand all that.
>
> i believe the idea is not for precomputing to be done by _builds_,
> but to be done on and for a given machine and its configuration,
> independent of any specific piece of software, which is then
> _queried_ by builds. That precomputation would only need to be
> re-run when one of the things under its purview changes.
>
> If i compile something on one of my OpenBSD boxen in the morning,
> and then compile some other thing in the afternoon, without an OS
> upgrade in-between, autoconf isn't going to find that libc.so has
> changed in-between. If i did the same thing on my Gentoo box, it's
> theoretically possible that e.g. i've moved from glibc to musl
> in-between, but in that case, precomputation could be done in
> postinst (i.e. as part of the post-installation-of-musl process).
>

Isn't that what thecautoconf cache is for?

Warner

>