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 D017B22AF8 for ; Fri, 21 Jun 2024 00:36:10 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 6034843C6C; Fri, 21 Jun 2024 08:36:02 +1000 (AEST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by minnie.tuhs.org (Postfix) with ESMTPS id 67E9743C6B for ; Fri, 21 Jun 2024 08:35:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=makerlisp.com; s=s1-ionos; t=1718922953; x=1719527753; i=luther.johnson@makerlisp.com; bh=urCHkmTY6DIhFHyv3ho0UCe0u9xUSwrGkS3A5AOj4qI=; 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=SQidhqbhw0Z61JwkBt0duQnPmoor9j248bCY2HKOM2r1RQRgZ1I+I0sGXSox6zrp 2ITGD1elgwnXIx26iQlC3bq7Z9Ils5rhVkKWygAdH5K8CmrmkL4WPQMr56ZizoUFN ILvWqvPFaJhWb8KwP6ruVPQAjBOY26ZUVcvuocFhB+IUjq4oy1aWH3woxcdk2dJvW GWjSWGqRxUpCGbv20N6e2flZQhCdH1WbQYNfoVkVkWJ/Je6vB3ioNY4FBFXnQ4o4Z uWOFY5sETsnQml3wjvoZ3OncXF+jHyvgLcJBtdAiMzKozsp7WNO+Caqed6OGN5NVC 6rfwwCPZw9VRxbQgaQ== 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 0LaEqu-1smHl11nf4-00iM62 for ; Fri, 21 Jun 2024 00:35:53 +0200 Received: from [192.168.234.136] (unknown [172.56.208.247]) by makerlispvps (Postfix) with ESMTPSA id B2A8D8C24D for ; Thu, 20 Jun 2024 22:35:52 +0000 (UTC) To: tuhs@tuhs.org References: <87iky84c23.fsf@gmail.com> <20240617012531.GE12821@mcvoy.com> <0e6792ed-65b0-e2e1-8159-6426a7f15a8d@riddermarkfarm.ca> <202406200501.45K5118a028500@sdf.org> <2a834aef-2b52-6b16-b79a-7f321585a4b8@makerlisp.com> From: Luther Johnson Message-ID: <532fcb28-74a2-896d-be1b-97d16f38f9bf@makerlisp.com> Date: Thu, 20 Jun 2024 15:35:50 -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="------------3E5196AEA2556B68B038553C" X-Provags-ID: V03:K1:i035fyq4XTo5iIGJBRUS+GzjZ8xmIB5puPkGLE190rwUVRLKdRs zCmfkJ9j/wO6xB+CHWZfnG0MV/Q+0T5fL83MHO/1X7awcSYiQymYgp6lGUuvsiO3dZSm+9y vgdCw8vSl9uwcWbyAdJpRS59l7aUi3RwrkGEEej+UL3kCXN03m7VYrgk77hzbwSSmTZZ4a2 pjeaYthbetHSUY6i+ZaWw== UI-OutboundReport: notjunk:1;M01:P0:kTQ5n0/855Y=;U0hrzZ6DE0/qkFenFz58uTgJn7A IRzKdnNwCkcy3ZvoS89v1mhFpLy8/tntt6FyaSkmSjxnmqZM38JJzr9wizxZO2/Ab4igGT+TJ qgKM5R1H5TEja/kUNL4J1H8SbqruCekOSbhpuSJSH1TCpDLkkDNcJVIHfKOZtNogWRV79LYAF aMGT/lV9gWlexbFW2HqcrPItBUSY5sHAZAnEVji5lAdj1CJpTkuhmlwr4YfCrIoz344SkwYqa KHCAfJePVdr+R8q/z2Awy3cY5zAtryV2/axp/JUUxdA5sS33K2Lyyedi50g5CITGgh/QqPgF2 oEiqdHRzWC9BgQ438wOHNvxEPxs2KeeqLh4ZsAjMIF3yxPQ1oN0RAS89qBWuBD7rveeE7s8lN +BgZjoXigUQ8O0AE3zZNNH6lNXw0blhqvaWUF0rLfo0xjfo/Pede8XK1+9RNS75lEek5Q/3S9 2i4hLHSQKwevBoVicDAa8NxBeDJd56mceKIIoocTyy3M+Gj2E3iAOscoa4j9cvYJSQH9JkPsp O6+cMLJTHjpA29SXYf2VhmF1qgJHroriXPNCO2PMfHQN1f4tCHbLWarsGZMmLJ61RF1Lx1xje FpMSXobYUUBbQLp6XiauCqnn41ahH3GU2OsIYJaOSYX9sn7a26eH65IyglY9M65ImarBedWDF Eis+Gp3Ahru6UL4G87EKnYsI+5pRHAYG0BZlEKnHj4y56Q7t6i5fra5dbEpmMqXrO8p2C6qf+ 4elRpsuzcaaz2EWXaphXmcKUcTPYrKOa3OczW2NQeNbwtQrgHslPc8= Message-ID-Hash: 2FZ45NXLTPSG47KFMMKXUDPNEWGWVUGQ X-Message-ID-Hash: 2FZ45NXLTPSG47KFMMKXUDPNEWGWVUGQ 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. --------------3E5196AEA2556B68B038553C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I defer to your greater experience than mine. I guess I've run into ./configure && make in very vanilla situations, a few Gnu or Gnu-ish applications. If it has times when it doesn't work, or doesn't behave well, then I don't doubt your experience. I first entered this thread in pointing out some similarities in the style of opaque artificially pseudo intelligence behind systemd and CMake, namely, don't you decide what to do, tell about these qualities of these modules and we will decide what to do, don't worry your newbie little head. I think autoconf and configure are kind of halfway between user-decides-what to do (straight make) and user-decides-nothing, is-kept-in the-dark (CMake). So in that way, it's only half as bad. If it falls over sometimes when it shouldn't I think you know more about that then me. I will be wary. For my own code, I stick with straight make, and the occasional script. On 06/20/2024 02:00 PM, ron minnich wrote: > here's where I'd have to disagree: "./configure && make is not so bad, > it's not irrational, sometimes it's overkill, but it works" > > because it doesn't. Work, that is. At least, for me. > > I'm amazed: the autoreconf step on slurm permanently broke the build, > such that I am having to do a full git reset --hard and clean and > start over. > > Even simple things fail with autoconf: see the sad story here, of how > I pulled down a few simple programs, and they all fail to build. I > replaced them ALL with a single Go program that was smaller, by far, > than a single one of the configure scripts. > https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK= 7clt_TmXo7c/edit?usp=3Dsharing > > On Thu, Jun 20, 2024 at 1:35=E2=80=AFPM Luther Johnson > > > wrote: > > I agree that there are certainly times when CMake's leverage has > solved problems for people. My most visceral reactions were mostly > based on cases where no tool like CMake was really required at > all, but CMake had wormed its way into the consciousness of new > programmers who never learned make, and thought CMake was doing > them a great service. Bugged the hell out of me, this dumbing-down > of the general programming population. My bad experiences were all > as a consultant to teams that needed a lot of expert help, when > they had thrown CMake along with a lot of other unnecessary > complexity into their half-working solutions. So I guess it was > all tarred by the same flavor of badly conceived work. But then as > I tried to make my peace with the CMake build as it was, I got a > deeper understanding of how intrinsically irrational CMake is (and > again, behavior changing on the same builds depending on CMake > release versions. > > So there certainly are times when something a little more > comprehensive, outside of make, is required. ./configure && make > is not so bad, it's not irrational, sometimes it's overkill, but > it works ... but only if the system is kind of Unix-y. If not you > may wind up doing a lot of work to pretend it's more Unix-y, so > instead of porting your software, you're porting it to a common > Unix-like subset, then emulating that Unix-like subset on your > platform, both ends against the middle. That can be ultimately > counter-productive too. > > I have an emotional reaction when I see the porting problem become > transformed into adherence to the "one true way", be it Unix, or > one build system or another. Because you're now just re-casting > the problem into acceptance of that other tool or OS core as the > way it should be. Instead of getting your thing to work on the > other platform, by translating from what your application wants, > into how to do it on whatever system, you're changing your > application to be more like what the "one true system" wants to > see. You've given up control of your idea of your app's core OS > requirements, you've decided to "just give in and be UNiX (or > Windows, or whatever)". To me, that's backwards. > > On 06/20/2024 12:59 PM, Warner Losh wrote: >> For me, precomputing an environment is the same as a wysiwyg >> editor: what you see is all you get. If it works for you, and the >> environment that's inferred from predefined CPP symbols is >> correct, then it's an easy solution. When it's not, and for me it >> often wasn't, it's nothing but pain and suffering and saying MF >> all the time (also not Make File).... I was serious when I've >> said I've had more positive cmake experiences (which haven't been >> all that impressive: I'm more impressed with meson in this space, >> for example) than I ever had with IMakefiles, imake, xmkmf, >> etc... But It's also clear that different people have lived >> through different hassles, and I respect that... >> >> I've noticed too that we're relatively homogeneous these days: >> Everybody is a Linux box or Windows Box or MacOS, except for a >> few weird people on the fringes (like me). It's a lot easier to >> get things right enough w/o autotools, scons, meson, etc than it >> was in The Bad Old Days of the Unix Wars and the Innovation >> Famine that followed from the late 80s to the mid 2000s.... In >> that environment, there's one of two reactions: Test Everything >> or Least Common Denominator. And we've seen both represented in >> this thread. As well as the 'There's so few environments, can't >> you precompute them all?' sentiment from newbies that never >> bloodied their knuckles with some of the less like Research Unix >> machines out there like AIX and HP/UX... Or worse, Eunice... >> >> Warner >> >> On Thu, Jun 20, 2024 at 12:42=E2=80=AFPM Adam Thornton >> > wrote: >> >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two >> letters it does, and I'm never going to believe it's "make file= ". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34=E2=80=AFAM Greg A. Woods >> > wrote: >> >> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS >> > wrote: >> Subject: [TUHS] Re: Version 256 of systemd boasts '42% >> less Unix philosophy' The Register >> > >> > "Greg A. Woods" > > wrote: >> > >> > > I will not ever allow cmake to run, or even exist, on >> the machines I >> > > control... >> > >> > I'm not a fan of cmake either. >> > >> > How do you deal with software that only builds with >> cmake (or meson, >> > scons, ... whatever the developer decided to use as the >> build tool)? >> > What alternatives exist short of reimplementing the >> build process in >> > a standard makefile by hand, which is obviously very >> time consuming, >> > error prone, and will probably break the next time you >> want to update >> > a given package? >> >> The alternative _is_ to reimplement the build process. >> >> For example, see: >> >> https://github.com/robohack/yajl/ >> >> This example is a far more comprehensive rewrite than is >> usually >> necessary as I wanted a complete and portable example >> that could be used >> as the basis for further projects. >> >> An example of a much simpler reimplementation: >> >> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/b= in/ctwm/Makefile?rev=3D1.12&content-type=3Dtext/x-cvsweb-markup&only_with_= tag=3DMAIN >> >> -- >> Greg A. Woods >> > >> >> Kelowna, BC +1 250 762-7675 RoboHack >> > >> Planix, Inc. > >> Avoncote Farms > > >> > --------------3E5196AEA2556B68B038553C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I defer to your greater experience than mine. I guess I've run into ./configure && make in very vanilla situations, a few Gnu or Gnu-ish applications. If it has times when it doesn't work, or doesn't behave well, then I don't doubt your experience.

I first entered this thread in pointing out some similarities in the style of opaque artificially pseudo intelligence behind systemd and CMake, namely, don't you decide what to do, tell about these qualities of these modules and we will decide what to do, don't worry your newbie little head. I think autoconf and configure are kind of halfway between user-decides-what to do (straight make) and user-decides-nothing, is-kept-in the-dark (CMake). So in that way, it's only half as bad. If it falls over sometimes when it shouldn't I think you know more about that then me. I will be wary.

For my own code, I stick with straight make, and the occasional script.

On 06/20/2024 02:00 PM, ron minnich wrote:
here's where I'd have to disagree: "./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works"

because it doesn't. Work, that is. At least, for me.

I'm amazed: the autoreconf step on slurm permanently broke the build, such that I am having to do a full git reset --hard and clean and start over.=C2=A0

Even simple things fail with=C2=A0autoconf: see the sad story here, of how I pulled down a few simple programs, and they all fail to build. I replaced them ALL with a single Go program that was smaller, by far, than a single one of the configure scripts.=C2=A0https://docs.google.com/presentation= /d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=3Dsharing

On Thu, Jun 20, 2024 at 1:35=E2=80=AFPM Luther Johnson <luther.johnson@ma= kerlisp.com> wrote:

I agree that there are certainly times when CMake's leverage has solved problems for people. My most visceral reactions were mostly based on cases where no tool like CMake was really required at all, but CMake had wormed its way into the consciousness of new programmers who never learned make, and thought CMake was doing them a great service. Bugged the hell out of me, this dumbing-down of the general programming population. My bad experiences were all as a consultant to teams that needed a lot of expert help, when they had thrown CMake along with a lot of other unnecessary complexity into their half-working solutions. So I guess it was all tarred by the same flavor of badly conceived work. But then as I tried to make my peace with the CMake build as it was, I got a deeper understanding of how intrinsically irrational CMake is (and again, behavior changing on the same builds depending on CMake release versions.

So there certainly are times when something a little more comprehensive, outside of make, is required. ./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works ... but only if the system is kind of Unix-y. If not you may wind up doing a lot of work to pretend it's more Unix-y, so instead of porting your software, you're porting it to a common Unix-like subset, then emulating that Unix-like subset on your platform, both ends against the middle. That can be ultimately counter-productive too.

I have an emotional reaction when I see the porting problem become transformed into adherence to the "one true way", be it Unix, or one build system or another. Because you're now just re-casting the problem into acceptance of that other tool or OS core as the way it should be. Instead of getting your thing to work on the other platform, by translating from what your application wants, into how to do it on whatever system, you're changing your application to be more like what the "one true system" wants to see. You've given up control of your idea of your app's core OS requirements, you've decided to "just give in and be UNiX (or Windows, or whatever)". To me, that's backwards.

On 06/20/2024 12:59 PM, Warner Losh wrote:
For me, precomputing an environment is the same as a wysiwyg editor: what you see is all you get. If it works for you, and the environment that's inferred from predefined CPP symbols is correct, then it's an easy solution. When it's not, and for me it often wasn't, it's nothing but pain and suffering and saying MF all the time (also not Make File)....=C2=A0 I was serious when I've said I've had more positive cmake experiences (which haven't been all that impressive: I'm more impressed with meson in this space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...=C2=A0 But It's also clear that different people have lived through different hassles, and I respect that...

I've noticed too that we're relatively homogeneous these days: Everybody is a Linux box or Windows Box or MacOS, except for a few weird people on the fringes (like me). It's a lot easier to get things right enough w/o autotools, scons, meson, etc than it was in The Bad Old Days of the Unix Wars and the Innovation Famine that followed from the late 80s to the mid 2000s.... In that environment, there's one of two reactions: Test Everything or Least Common Denominator. And we've seen both represented in this thread.=C2=A0 As well as the 'There's so few environment= s, can't you precompute them all?' sentiment from newbies that never bloodied their knuckles with some of the less like Research Unix machines out there like AIX and HP/UX...=C2=A0 Or worse, Eunice...

Warner

On Thu, Jun 20, 20= 24 at 12:42=E2=80=AFPM Adam Thornton <athornton@gmail.com> wrote:


Someone clearly never used imake...

There's a reason that the xmk= mf command ends in the two letters it does, and I'm never going to believe it's "make file".

Adam

On Thu, Jun 20= , 2024 at 11:34=E2=80=AFAM Greg A. Woods <woods@robohack.ca> wrote:
At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <= tuhs@tuhs.org> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> "Greg A. Woods" <woods@robohack.ca> wrote:
>
> > I will not ever allow cmake to run, or even exist, on the machines I
> > control...
>
> I'm not a fan of cmake either.
>
> How do you deal with software that only builds with cmake (or meson,
> scons, ... whatever the developer decided to use as the build tool)?
> What alternatives exist short of reimplementing the build process in
> a standard makefile by hand, which is obviously very time consuming,
> error prone, and will probably break the next time you want to update
> a given package?

The alternative _is_ to reimplement the build process.

For example, see:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://git= hub.com/robohack/yajl/

This example is a far more comprehensive rewrite than is usually
necessary as I wanted a complete and portable example that could be used
as the basis for further projects.

An example of a much simpler reimplementation:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://cvsw= eb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=3D1.1= 2&content-type=3Dtext/x-cvsweb-markup&only_with_tag=3DMAIN

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Greg A. Woods <gwoods@acm.org>

Kelowna, BC=C2=A0 =C2=A0 =C2=A0+1 250 762-7675=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>=C2=A0 =C2=A0 =C2=A0Avoncote Farms <woods@avoncote.ca>


--------------3E5196AEA2556B68B038553C--