[TUHS] Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
Warner Losh
imp at bsdimp.com
Fri Jun 21 10:05:29 AEST 2024
On Thu, Jun 20, 2024, 5:35 PM Alexis <flexibeast at gmail.com> wrote:
> Bakul Shah via TUHS <tuhs at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240620/21909841/attachment.htm>
More information about the TUHS
mailing list