From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 1F28421FFC for ; Fri, 21 Jun 2024 02:05:54 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id E7A7D43C74; Fri, 21 Jun 2024 10:05:48 +1000 (AEST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by minnie.tuhs.org (Postfix) with ESMTPS id D442943C75 for ; Fri, 21 Jun 2024 10:05:41 +1000 (AEST) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2c70c372755so1244084a91.1 for ; Thu, 20 Jun 2024 17:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1718928341; x=1719533141; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=W4ujKdAR5KRlmyqTFDDvFJLNe02q5IAqrG8jkm7d9m0=; b=x0wIkwjhdXqjjhaEt2F+Zpl8ySSVkKwTn32E+cjRLdhREeJJ7RT4FNAOOI7M9JqDFT 81TLiHjW7N1y+JnV82oeCTNIjK3Dh8tFxVjHZPVlVhS1yeLDZkMVOpt22aNs6sWHWc9q Oe6yDXGa9C5/CcnqQOq2YZH878FXDZjTLi78qBNXgMzYQocUEeANKdZD1FQYn+bkJwSv hdC5uhB0LGsxgcxRrh736Z2QDD4N5plRww2qxP1vh8gY2lZBPe4mj40GTt7b439wUr3Q /BIU2r/++PC47P9eCxGvbcN4+oS0EOBdFmpzclToXY/n28nS0ntoQj564ryGAhLwZbqz E4yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718928341; x=1719533141; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W4ujKdAR5KRlmyqTFDDvFJLNe02q5IAqrG8jkm7d9m0=; b=qJEORPzf5WtaAngxrkWY9CRkhGXfu5hYQ3MG/voPnKQYjNZzYCY5TnuLxVXPOgz96o 6NSXkeBCJboOtnFhSuyFPc+qq1aDpy23vrN4OhDI+6T5yN9FTdU/x+3N3FKAkwk6VVdi k7KPM/QKh+yiEwy0UGXejkRv06F9EJyQfEinapL61E2AeJaNPn3JK8r8lLvuQl+s3G4z jvbPMHki9LexjzCPHIGYzq3uy2KSC1q0GE3Z5s0cFwBkFUUnXJ1HZx7G6QGgD8IiJ4y3 Pebu/kxG+BQiYxIJWuYEDm/jLRscN7z/g+oNltsSNgKW8yW8NkrL4yHvVPOrF2MEXgGo cf6Q== X-Gm-Message-State: AOJu0Yzs3x3YkYC+DGdrGhrJTvf4DqwUi8DpFcXr3R0rG8vzG5FR0On6 OKkPEI0yTjj59AT0cZ2tj5VoJ9k1kqHMyxtBVL3Bzota7WbeE7LhH+ao+JvqXNVqbU4PxE4m49Q CrY3fFwV+JD+hZ4A13+nqiFpCcaH4UR4zCSODWw== X-Google-Smtp-Source: AGHT+IHc92t8DuZcA6C3dddVC6ByV37OZU0xTSGBQnYr9XZ6NMu/IwUta460c8a55C+7vcOVLnfSv4oRoCG/4OtLE2U= X-Received: by 2002:a17:90a:e795:b0:2c8:9d1:2de9 with SMTP id 98e67ed59e1d1-2c809d13305mr1894489a91.7.1718928340963; Thu, 20 Jun 2024 17:05:40 -0700 (PDT) MIME-Version: 1.0 References: <87jzikt900.fsf@gmail.com> <877cej5gsp.fsf@gmail.com> In-Reply-To: <877cej5gsp.fsf@gmail.com> From: Warner Losh Date: Thu, 20 Jun 2024 18:05:29 -0600 Message-ID: To: Alexis Content-Type: multipart/alternative; boundary="0000000000002872d1061b5b31bc" Message-ID-Hash: LNI5JNLK5BODUAHC5WTEE767A43ZLOXA X-Message-ID-Hash: LNI5JNLK5BODUAHC5WTEE767A43ZLOXA X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Unix Heritage Society , Bakul Shah X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002872d1061b5b31bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 20, 2024, 5:35=E2=80=AFPM Alexis wrote: > Bakul Shah via TUHS 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 > --0000000000002872d1061b5b31bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 20, 2024, 5:35=E2=80=AFPM Alexis <flexibeast@gmail.com> wrote:
<= /div>
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
--0000000000002872d1061b5b31bc--