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 [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 6A49F21833 for ; Fri, 21 Jun 2024 16:00:46 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DF4E0432F1; Sat, 22 Jun 2024 00:00:40 +1000 (AEST) Received: from fout6-smtp.messagingengine.com (fout6-smtp.messagingengine.com [103.168.172.149]) by minnie.tuhs.org (Postfix) with ESMTPS id 28EE8425D9 for ; Sat, 22 Jun 2024 00:00:35 +1000 (AEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 7FFAC1380241; Fri, 21 Jun 2024 10:00:34 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Fri, 21 Jun 2024 10:00:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1718978434; x=1719064834; bh=Tq+vlTzBbS TyHU/N2DLl7Q4eImUAoh9omjEBLM4s6Gg=; b=eWvURGl0cLz808ITQWsRwlJtst cfKAZTEVhsTmjMD261w+5DEZGEZd57nafKZUjsiznmpl76rLBntQ+FmZHeY7177Y qAsonRDexdgipxmbDXBNAPjF0SqOjFguCkaUUs4ubI5d4G3cspv71GX7QTRA+2Xo 66uqzowmHMkxt/4yeOpi0qd85yxj3v48ieJxtqKfZ82TIzN9jlXXxDFwhZolK4ZX tUs7LJzKxxb3Czo+XQN2F38zgN9diDjvLMsUBCd+kv712BRGKwLbZl24piswT56+ G0N1z9g/ZJc2qqcryPOwPmf73T++G/EycWuKTJiuSD8UpTtAZ1mPjJKrC4cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1718978434; x=1719064834; bh=Tq+vlTzBbSTyHU/N2DLl7Q4eImUA oh9omjEBLM4s6Gg=; b=TtK4cdvBoTfHI3GPYaCUJb/yFVV68xOfLdF81zYdB8ir OtaUmABEC5UTgPNStLt37mDTh3HmCU0i8ClYxw03ZAMqLsePbvuSr6uhL3+yN4PM g2OgVqlM9dXJZ+Ww7xkdmX1BzmBr16Ji1VQP1ucU1tUQQ8W9G93XztY8G/3tG00x ToFrEsJ14uFsxF4C2Vgs+Rz0ny6R38EkG5YD4XXymZJnR14P6uJ+hcdTwz39vFsD mFt2Mh58qtdgBp+mXjhOqxUdKE7jS+3u092Eu1tgKGt24UQzf+c45g7UCfqc+kdy dgoJpkzGYqJQWeE1cJK3Vx5pI1H7k8i0Lq4z1HXo/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefgedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgr nhcuffdrucfurghlvgifshhkihdfuceorggushesshgrlhgvfihskhhirdgvmhgrihhlqe enucggtffrrghtthgvrhhnpeejvdejheeutefhtedtudektdegfeeivdelveeggfehkeeg veeikeeludffkeekleenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggushesshgrlhgvfihs khhirdgvmhgrihhl X-ME-Proxy: Feedback-ID: if9414728:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id F3A9E272008F; Fri, 21 Jun 2024 10:00:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d MIME-Version: 1.0 Message-Id: In-Reply-To: References: <87jzikt900.fsf@gmail.com> <877cej5gsp.fsf@gmail.com> <87bk3vf64u.fsf@gmail.com> Date: Fri, 21 Jun 2024 09:58:36 -0400 From: "Alan D. Salewski" To: "TUHS (The Unix Heritage Society)" Content-Type: text/plain Message-ID-Hash: 4WL5ZDOUQNKF3HPUIOHLGXLFGL6EGXNO X-Message-ID-Hash: 4WL5ZDOUQNKF3HPUIOHLGXLFGL6EGXNO X-MailFrom: ads@salewski.email 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 21:43, segaloco via TUHS wrote: > On Thursday, June 20th, 2024 at 6:15 PM, Alexis wrote: > [...] >> The basic things are, in fact, a significant part of what autoconf >> is being used to check for. "Does this platform provide this >> function?" >> >> ... >> >> >> 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 > instance, 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 that doesn't justify all the machinery between > one's self and make just to provide. 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 already 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 > headaches 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 figure 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. [...] The thing about the autotools is that there are two different audiences for different aspects of the system: consumers of the package (sysadmins, porters, distro packagers...) and developers. In general, the developers need to work a little harder to make life of the consumers easier. While some consumers might be fine with (to use the example above) a cpp error diagnostic about a missing include, I imagine most would prefer a "configure time" diagnostic explaining that dependency package foo needs to be installed before they try to build it. Those who are not C or C++ developers wouldn't necessarily know what cpp is, or how to control it.[0] I, for one, appreciate that pretty much any build tool can be integrated into the autotools framework, in part because it acts as a barrier between the consumers and the underlying language-specific build tooling, etc. The same could be (and has been) said of portable Makefiles, but the level of effort would be quite high to achieve what the autotools-generated Makefiles produce out of the box. E.g., the 'make distcheck' target not only drives a full configure and build in a temporary directory, but also verifies that a VPATH build (building separately from the source tree) works. Language-specific build mechanisms are fine as far as it goes. But the more of them you encounter and need to interact with directly, the more friction there is. The audience for such tools is primarily the developer. Python's pip, JavaScript's npm (or yarn, or ...), golang, Rust's cargo, Java's mvn (or ant, or ivy, or ...), Clojure's lein, Perl's ExtUtils::MakeMaker (or Module::Build, or ...), Ruby's gem, ... And tooling to produce documentation is even worse: DocBook, AsciiDoc, reStructuredText. Even driving LaTeX has become complicated (PDFLaTeX, XeTeX, LuaTeX, ...). The developer who necessarily understands such things can, with some effort, integrate them into an autotools build, making life much easier for the consumers of the package (assuming the integration has been done well). When the audience or consumer of the package is sysadmins (including end-users acting as their own sysadmin), porters, and distro packagers, I think "the usual dance" of "./configure && make" is nice because it is consistent across underlying languages, compilers, and whatever auxiliary tools are needed to produce documentation, etc. And I happen to like m4 :-) *ducks* -Al [0] Sadly, the days when C was the lingua franca amongst programmers seem to be behind us. -- a l a n d. s a l e w s k i ads@salewski.email salewski@att.net https://github.com/salewski