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 [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 97B2421626 for ; Wed, 19 Jun 2024 05:07:16 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 442F543317; Wed, 19 Jun 2024 13:07:11 +1000 (AEST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by minnie.tuhs.org (Postfix) with ESMTPS id B5115431A0 for ; Wed, 19 Jun 2024 13:07:04 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=makerlisp.com; s=s1-ionos; t=1718766423; x=1719371223; i=luther.johnson@makerlisp.com; bh=qme2ROHJw2Vi8WrE/d+/TlCNaA1xmOIXegrZQFQR44A=; h=X-UI-Sender-Class:Subject:To:References:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=a5oYQplBaddQ3Bk+G43R71PXEzXicYYdlQxblkMDUgShXFUDHdRDxk5JIJgae9gJ 49LnjeYNGMIPSadM/OV+IKvzdVKcpneM3qI6UcxhK50a3qGNHs13fzgzjuCxAlfJt ozPNb+GnnVn7Fz3uESVYpvga752ejiqirswrlqu8uXBwEo7JV0mHtXsr8oMuo4n78 EUUNrJ5x+UASVsMCU6UqUbsifZ3tLzX19mdM5Cehg3TBpzJDX9HDR0CC2w7K0Ny5R +6+bS3/+l1uuTcqBPdT9FYYF3+dyFIZN8RBrVH8XJe+YZ6/6kFwSgB54TQcuDni9o zeZWfRy0uVAwYOr1sw== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from makerlispvps ([74.208.29.250]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lg28r-1shrwa1qf5-00nasa for ; Wed, 19 Jun 2024 05:07:03 +0200 Received: from [192.168.234.136] (unknown [172.56.209.165]) by makerlispvps (Postfix) with ESMTPSA id D4A4C8C238 for ; Wed, 19 Jun 2024 03:07:02 +0000 (UTC) To: tuhs@tuhs.org References: <87msnl4ew0.fsf@gmail.com> <87iky84c23.fsf@gmail.com> <20240617012531.GE12821@mcvoy.com> <0e6792ed-65b0-e2e1-8159-6426a7f15a8d@riddermarkfarm.ca> <9f9db0d2-8a6a-26cc-a0ba-b6fc5d6474cb@makerlisp.com> From: Luther Johnson Message-ID: Date: Tue, 18 Jun 2024 20:07:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D90C5FD4454B0A44F86A0F03" X-Provags-ID: V03:K1:jh68IVCHu7qttlwBl1pJtYxq1LUVXb4LJeA0BrV84vYJ9GXEF4x szyxdMlr147CGoHSEeGSImbj2IxePxbCJkSbVux+bDk8CXkIJlp8R5mc+gFrHN/ZFPk305N S+mLw8bvH9W2p/B6jeTtvPvyDMv+b9M/HfAw7lPe4dRFrc59OCQhNZRbeZj3Isvu6PxzhpJ Uw+5d0ixyGGwx6sHPB3xQ== UI-OutboundReport: notjunk:1;M01:P0:KHGzurOBoJY=;Cqw6a3NG1yhKWIx3FoC5x3QOzzv 6c6bNxxoGWQKe+YBQ+P00E9dGRZ65Dxatk7KnGZIi+rF64jt072s82KhLQFdPGRb84pvZrUal CAECz9zux6dyjmZxi5XzXFvJIJmtxvSiJny9xWovuwrddWbUIdQS9AY9mNwj8Zja/lF0qSJSY fSDmsUwZ+loBezfEMcNxuVZ4BCWYJ7kG79FA/IU6pwDjG1FsC1OVWBLtrZ/1nhkMa4orcZaHc XnpH083eGgSb2dk6ujac5o/RuMFh0eTWeL9HRGArdvE9u9+5pqCwue2sKfKxEMKz/ECU56Tob xndHlyBYT9Nk/918ZWuPdJXdW7/+DWbkuH4icjuY7bMjuYgOP5Kf8prWqwy8abbrZPu7rWUnR npO6RIuAkrzfGEjhVWiOpKmm8nW87lk5NoK2JybaUMk0AyQPCzC8o/gw8DfVqD16a2zNpJxUc zwjZMg0JpA3SMhHHTVQOj2xkYKuZ3hs91AziiLkT7cZPs7Y3RgYO8BZud/LZHm9QRU/NTj4bK jdmLYNiTcXWwUuXlfoDP+p2JCtTNL0fwKbFGkbCTZXk1vGlMYYuuCozKv/NNGfL4Lr2Q+HqxV kiUjsmTyAZ5mMrUyAJupR0Vo6dwY0rpsbKaSIKRiuksX3CD5ecVMcfg7MDJhrgSoHQq5arblo e7kAuG5/oyeAphDjZTWFSBP+UC7fWWPdzX1ggSfCA43UN1muhRQOHo2BDfpdzpCIaGhuLgQa0 BGrbBfB19nxHsLqZu69bBqGUCvl5jfEexol0b4TcvexXagGg3YuziQ= Message-ID-Hash: UGZX5T4YDYLBX5BQVXKI2WQLUI7KUUTB X-Message-ID-Hash: UGZX5T4YDYLBX5BQVXKI2WQLUI7KUUTB X-MailFrom: luther.johnson@makerlisp.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: 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: This is a multi-part message in MIME format. --------------D90C5FD4454B0A44F86A0F03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I don't think any makefiles I've written do all of that. I guess I don't expect all of that in one place. So i will have some makefiles that are really portable, because they are very compute-bound or their interface to the world is something else generic, like files. And then for more platform-specific parts I would have different makefiles for different platforms. One-button, one command-build (that seems) identical for all platforms, is not that important to me. And yes, sometimes I write scripts to do the parts of a build in sequence. And I don't consider any of this 'hard', but I'm not trying make the builds look like they are the same, even if they are really quite different. The GNU ./configure, make model is one model. CMake and other makefile generators are another. But I have used several compilers or other general purpose tools that have more than one makefile or build script, depending on the platform, and I just take the tool for what it is, and use it. And when I have to debug or change something about the build, it's MUCH easier to work with makefiles and build scripts than it is to extend configure scripts, or extend a build-specification in a build-tool-specific language. In my experience, so far. But some people will get into configure and/or CMake or any of the others and learn how to be productive that way. More power to them, but I don't enjoy doing that. When I have had to use CMake, it seemed to require more specification on my part to generate all sorts of crufty state, so every build was not necessarily the same, unless I used the right commands or deleted all these extra directories full of persistence from the last CMake or build, to write all these weird, generated, unreadablemakefiles calling makefiles, doing no more than I could easily do by hand in one makefile. No, my hand-written makefiles will not be absolutely universal, or appear to be, but they will work in a way I can predict, and that is of great value to me. On 06/18/2024 05:46 PM, Nevin Liber wrote: > On Tue, Jun 18, 2024 at 7:09=E2=80=AFPM Luther Johnson > > > wrote: > > I agree with Greg here. In fact even if it was well done, it is > declaring something that wasn't really a problem, to be a problem, t= o > insert itself as the solution, but I think it's just extra stuff and > steps that ultimately obfuscates and creates yet more dependencies. > > > That's a really bold claim. You may not like the solution (I don't > tend to comment on it because unlike some here, I recognize that build > systems are a Hard Problem and I don't know how to make a better > solution), but that doesn't mean it isn't solving real problems. > > But I'll bite. There was the claim by Larry McVoy that "Writing > Makefiles isn't that hard". > > Please show these beautiful makefiles for a non-toy non-trivial > product (say, something like gcc or llvm), which make it easy to > change platforms, underlying compilers, works well with modern > multicore processors, gets the dependencies right (one should never > have to type "make clean" to get a build working correctly), etc. and > doesn't require blindly running some 20K line shell script like > "configure" to set it up. > -- > Nevin ":-)" Liber iber@gmail.com > > +1-847-691-1404 --------------D90C5FD4454B0A44F86A0F03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I don't think any makefiles I've written do all of that. I guess I don't expect all of that in one place. So i will have some makefiles that are really portable, because they are very compute-bound or their interface to the world is something else generic, like files. And then for more platform-specific parts I would have different makefiles for different platforms.

One-button, one command-build (that seems) identical for all platforms, is not that important to me. And yes, sometimes I write scripts to do the parts of a build in sequence. And I don't consider any of this 'hard', but I'm not trying make the builds look like they are the same, even if they are really quite different. The GNU ./configure, make model is one model. CMake and other makefile generators are another. But I have used several compilers or other general purpose tools that have more than one makefile or build script, depending on the platform, and I just take the tool for what it is, and use it. And when I have to debug or change something about the build, it's MUCH easier to work with makefiles and build scripts than it is to extend configure scripts, or extend a build-specification in a build-tool-specific language. In my experience, so far. But some people will get into configure and/or CMake or any of the others and learn how to be productive that way. More power to them, but I don't enjoy doing that. When I have had to use CMake, it seemed to require more specification on my part to generate all sorts of crufty state, so every build was not necessarily the same, unless I used the right commands or deleted all these extra directories full of persistence from the last CMake or build, to write all these weird, generated, unreadablemakefiles calling makefiles, doing no more than I could easily do by hand in one makefile. No, my hand-written makefiles will not be absolutely universal, or appear to be, but they will work in a way I can predict, and that is of great value to me.

On 06/18/2024 05:46 PM, Nevin Liber wrote:
On Tue, Jun 18, 2024 at 7:09=E2=80=AFPM Luther Jo= hnson <luther.johnson@ma= kerlisp.com> wrote:
I agree with Greg here. In fact even if it was well done, it is
declaring something that wasn't really a problem, to be a problem, to
insert itself as the solution, but I think it's just extra stuff and
steps that ultimately obfuscates and creates yet more dependencies.

That's a really bold claim.=C2=A0 You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems.

But I'll bite.=C2=A0 There was the claim by Larry McVoy tha= t "Writing Makefiles isn't that hard".

Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up.
--
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:n= liber@gmail.com>=C2=A0 +1-847-691-= 1404

--------------D90C5FD4454B0A44F86A0F03--