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=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,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 A714120CD8 for ; Fri, 21 Jun 2024 03:44:08 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 1815543CAE; Fri, 21 Jun 2024 11:44:05 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1718934245; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=ff84PhdjNyKTHa/8m6bmQN3fuN7N7j5ir2ebJkLsF50=; b=O9Jn7iszbgfNXRve5GQSA6fo9xzXU7/fk9uvwKZn13Ib65kW22r88kNZXWNTvnHWPJceSX Wman+gHwYuE+MQxUAGyt4KUbX0TUv6tkWZ/KnY5vZ4e10XPBMO0kp6371E4hQxKEjSRuhM le+mUCJvo8sAfvG9rIZzWywQcQV5FO0= Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by minnie.tuhs.org (Postfix) with ESMTPS id 36E1443CB5 for ; Fri, 21 Jun 2024 11:44:01 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1718934239; x=1719193439; bh=ff84PhdjNyKTHa/8m6bmQN3fuN7N7j5ir2ebJkLsF50=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=pS1DH1S8dHw6UXdWETnZuWZGzT7iIcS2roaJhyJHG9jKx6IL/t8mkywi0eR96X/u+ 11gnc+hdQZvBuEBvDqSU6M1uJo8LJVJDOeaquAer5UQvi+4JZzmiRaWHt3FGfweJ9D K/rJht6i7Hw6MNm/sZOG1Kwsb+Au+nBs5HmdpM3NhlR3XS2Sc6VHP+dzyS0Iblw44y i9e6ZaZHf0pJt0c0xuCPAQyyIC83ASr0578sXB4k82Wztg6uGu4/IzO42TJ2QV3Upq oork9NfewcLdDbabAKaXUJhyEZAUNYFnXq6/UGxibBB5NzD6CwxP9Y7or7CbQorE13 EZsGuQJHyZcQQ== Date: Fri, 21 Jun 2024 01:43:54 +0000 To: The Eunuchs Hysterical Society Message-ID: In-Reply-To: <87bk3vf64u.fsf@gmail.com> References: <87jzikt900.fsf@gmail.com> <877cej5gsp.fsf@gmail.com> <87bk3vf64u.fsf@gmail.com> Feedback-ID: 35591162:user:proton X-Pm-Message-ID: 4961161d2083311b4225679d937633e31c2eed80 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: CQ6GMQ4IKGWFKEEQ5I2TEVN7UNXXAP6N X-Message-ID-Hash: CQ6GMQ4IKGWFKEEQ5I2TEVN7UNXXAP6N X-MailFrom: segaloco@protonmail.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: From: segaloco via TUHS Reply-To: segaloco On Thursday, June 20th, 2024 at 6:15 PM, Alexis wrot= e: > Bakul Shah bakul@iitbombay.org writes: >=20 > > 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. >=20 >=20 > The basic things are, in fact, a significant part of what autoconf > is being used to check for. "Does this platform provide this > function?" > > ... >=20 >=20 > Alexis. This aspect of things I have found a bit perplexing. On one hand, sure, it= 's nice to have some scripted system spit out a: "Dependency xyz not found" But where it falls apart in my head is what that tells me that, for instanc= e, cpp's error diagnostic about a missing include or ld saying a symbol or = library wasn't found does. It's in my mind a minor convenience but one tha= t doesn't justify all the machinery between one's self and make just to pro= vide. Granted that's not all autotools does, so a poor example in practice= , but in theory gets at one of my irks, packaging something that you are al= ready going to discover some other way. That and "does my target platform = list support xyz" isn't necessarily a matter I'd wait until I've created a = whole build package around my software to settle... Just a small part of the puzzle but one of the parts that gives me more hea= daches than not. Now I don't get to respond to a compiler or linker asking= for something by putting it where it asked for it, now I also have to figu= re out how to do the extra work to ensure that it's put somewhere and in a = way that all this machinery between myself and the compiler can also verify= in its own magical way component is present. I'd be willing to wager that half the time autotools, cmake, etc has made m= e want to put my head through a wall is not that some needed thing isn't th= ere, it's just that it's not there according to whatever extra expectations= or formulas come into play just to satisfy the build machinery. These too= ls can be helpful in the face of extreme complexity, but I feel silly when = most of the work I put into compiling some package that's like 6 source fil= es is making sure the environment on my system can satisfy the expectations= of the build tools. It has been said already that part of the problem too with the uptake of th= ese tools and their growing ubiquity is new folks who don't know any better= think that's just "how it is" and then wind up spinning an autotools or cm= ake build for a <1000 line tool written in ANSI C. I've done the same in l= ess experienced times, one of my first attempts at a game engine uses an au= totools build. I quickly grew frustrated with it and everything since has = used a flat makefile and has been just fine. Granted I'm not building a tr= iple A game, but that gets at the root of one of my gripes, I think these s= orts of frameworks are overused. They have their areas that they shine, or= they wouldn't have reached the critical mass they have, but as consequence= folks will use them haphazardly regardless of the need. Long story short, maybe gcc needs a configure script, but does GNU ed? May= be KDE Plasma needs CMake files, but does libtiff? I make no claims regard= ing the complexity of these actual codebases...but one does have to wonder.= .. - Matt G.