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,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 4F4EA23846 for ; Fri, 21 Jun 2024 03:44:35 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 97C8643CB1; Fri, 21 Jun 2024 11:44:31 +1000 (AEST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by minnie.tuhs.org (Postfix) with ESMTPS id 6017143CBD for ; Fri, 21 Jun 2024 11:44:27 +1000 (AEST) Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1f9885d5c04so13658125ad.0 for ; Thu, 20 Jun 2024 18:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1718934266; x=1719539066; darn=tuhs.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PfijMEWackNrfyh0hvPEVEi4/ACE0ZYJjsKGopPlcxk=; b=NaxwsgLElYtoPqsZPGs36k7i2qW1jxofC+VXTBNiMfyPBunmWDEHwVu1pEJlqsqd73 37rd4HsIBHybIWErQqDCjGzV0ivOAdyq/xgDE8bXw9/j0tCAIN33pPMS8/hbqsil0KVt U51uV7Fasb3ouCmY8T3fIIaLdHG+0XZpiAR0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718934266; x=1719539066; h=content-transfer-encoding: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=PfijMEWackNrfyh0hvPEVEi4/ACE0ZYJjsKGopPlcxk=; b=Nta7aW/yFyw1mULcf5mRiybPu5xX3XldUjwE6/Mhw6ASxKqL5vn9TMEwd3Rklgaol1 GBFhuJXJsZ1WGI4D3KnDs6U+QywKWt1H4lR6NBHW7CkASUELc6VdbjqYNmlVUoEhxDa1 B8UIka0mwUtyXFsXliuISHsnHSKHV9CoMRaMYesPY/krlyl8IgpM0MtPCIYwlj81+dL7 4ANVNqtdU83iTBQVtpr9rKDARhb/LVXAadgZ6ai9DwfiBcY+EC/onzhnLwjJElu1byb7 yNA4Ny0T9jv6ihF8EtRCynkFoCQOeeMAFAu24U2l5em2Rm/hvnwaosY/hsnd+58/igUk ex9g== X-Gm-Message-State: AOJu0YxdiUJOb0FDULrcjfMXzfKHNpcKdAeJGv0OGlVjK4Erb3f2gB91 owV+UWqo/saerGAskeyPZIMJ3+9YXuCNe15KszUOX71zVhe8aYVoSXdgZVZxuhuxx6iOIluyQ4q QjbnxJKzoze+jScb3woA2E2oYkF7a73kjbjdu41y+k8lwg5FLRJUw X-Google-Smtp-Source: AGHT+IHu6q43uR4AJH8yVQ4xPvFzMxm3oTESmRLEYCtEJ75LrLwkBwmnKyTEQrAiif+1EZQZ/tSbGpnuB0oecx7xT7o= X-Received: by 2002:a17:90a:f2c2:b0:2c7:cc35:2819 with SMTP id 98e67ed59e1d1-2c7cc354740mr5049737a91.3.1718934266026; Thu, 20 Jun 2024 18:44:26 -0700 (PDT) MIME-Version: 1.0 References: <87jzikt900.fsf@gmail.com> <877cej5gsp.fsf@gmail.com> <20240621003532.GA13079@mcvoy.com> <87frt7f7c1.fsf@gmail.com> In-Reply-To: From: Kevin Bowling Date: Thu, 20 Jun 2024 18:44:14 -0700 Message-ID: To: The Unix Heritage Society mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ULYY2IZRXN7VD2YSZKNJOSHQLKANKK3K X-Message-ID-Hash: ULYY2IZRXN7VD2YSZKNJOSHQLKANKK3K X-MailFrom: kevin.bowling@kev009.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 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: On Thu, Jun 20, 2024 at 6:22=E2=80=AFPM Greg A. Woods w= rote: > > At Fri, 21 Jun 2024 10:49:34 +1000, Alexis wrote: > Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts = '42% less Unix philosophy' The Register > > > > So, > > to what extent is the complexity of > > autoconf _needed_ nowadays? > > For xz in particular Autoconf is _probably_ not necessary, but I haven't > examined it in detail. > > For a vast amount of application C code and libraries no build-time > configuration beyond what's provided by the system headers and the C > compiler is necessary. This is especially true if the code is designed > to require a slightly "modern" version of C, such as iso9899:1999 > (perhaps with GNU CC extensions). > > There are however some things in more systems level programs and > libraries that are more difficult to handle even with well written code, > but compared to the number of tests offered by the likes of Autoconf, > well those things are actually very few. Warner sufficiently summed up the philosophical reason for the probe-the-world-after-slumber approach. It seems foolish at first; a waste of time/cycles; but the deeper you dig into the problem space the less foolish it becomes. As an example, autoconf builds easily handle cross toolchains or shimmed toolchains where a mix of native and emulated tools are used to speed up cross builds. I agree with the chorus that the implementation of autoconf is awful. But the audience that assume that autoconf is also bad, and the bits and bobs of shell and make are somehow equivalent, is living in a state of willful ignorance. > One thing that Autoconf gets used for, but for which it is not really > necessary, is for choosing build-time options. Indeed its feature set > for doing so is complex and error-prone to use! Too much weird mixing > of shell scripts and M4 macros, with all the quoting nightmare this > brings. Just try to read XZ's configure.ac! A simple declarative > configuration file, such as a Makefile fragment, is sufficient. > > When you wander into the realm of non-C code things might also be a bit > more complex, unless of course it's Go code, where this problem simply > doesn't exist in the first place. Go's approach was the same as Java, if you control the level of abstraction sufficiently you eliminate much of the complexity. > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms