<div dir="ltr">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"<div><br></div><div>because it doesn't. Work, that is. At least, for me.</div><div><br></div><div>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. </div><div><br></div><div>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. <a href="https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing">https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson <<a href="mailto:luther.johnson@makerlisp.com">luther.johnson@makerlisp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>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.<br>
</p>
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.<br>
<br>
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.<br>
<br>
<div>On 06/20/2024 12:59 PM, Warner Losh
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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...</div>
<div><br>
</div>
<div>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...</div>
<div><br>
</div>
<div>Warner<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at
12:42 PM Adam Thornton <<a href="mailto:athornton@gmail.com" target="_blank">athornton@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="margin-left:40px"><br>
</div>
<div style="margin-left:40px"><br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Someone
clearly never used imake...</blockquote>
<div style="margin-left:40px"><br>
</div>
<div style="margin-left:40px">There's a reason that the <span style="font-family:monospace">xmkmf </span><font face="arial,sans-serif">command ends in the two
letters it does, and I'm never going to believe it's
"make file".</font></div>
<div style="margin-left:40px"><font face="arial,sans-serif"><br>
</font></div>
<div style="margin-left:40px"><font face="arial,sans-serif">Adam<br>
</font></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at
11:34 AM Greg A. Woods <<a href="mailto:woods@robohack.ca" target="_blank">woods@robohack.ca</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At Thu, 20 Jun 2024
01:01:01 -0400, Scot Jenkins via TUHS <<a href="mailto:tuhs@tuhs.org" target="_blank">tuhs@tuhs.org</a>> wrote:<br>
Subject: [TUHS] Re: Version 256 of systemd boasts '42%
less Unix philosophy' The Register<br>
><br>
> "Greg A. Woods" <<a href="mailto:woods@robohack.ca" target="_blank">woods@robohack.ca</a>>
wrote:<br>
><br>
> > I will not ever allow cmake to run, or even
exist, on the machines I<br>
> > control...<br>
><br>
> I'm not a fan of cmake either.<br>
><br>
> How do you deal with software that only builds with
cmake (or meson,<br>
> scons, ... whatever the developer decided to use as
the build tool)?<br>
> What alternatives exist short of reimplementing the
build process in<br>
> a standard makefile by hand, which is obviously
very time consuming,<br>
> error prone, and will probably break the next time
you want to update<br>
> a given package?<br>
<br>
The alternative _is_ to reimplement the build process.<br>
<br>
For example, see:<br>
<br>
<a href="https://github.com/robohack/yajl/" rel="noreferrer" target="_blank">https://github.com/robohack/yajl/</a><br>
<br>
This example is a far more comprehensive rewrite than is
usually<br>
necessary as I wanted a complete and portable example
that could be used<br>
as the basis for further projects.<br>
<br>
An example of a much simpler reimplementation:<br>
<br>
<a href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN" rel="noreferrer" target="_blank">http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN</a><br>
<br>
--<br>
Greg A. Woods
<<a href="mailto:gwoods@acm.org" target="_blank">gwoods@acm.org</a>><br>
<br>
Kelowna, BC +1 250 762-7675 RoboHack <<a href="mailto:woods@robohack.ca" target="_blank">woods@robohack.ca</a>><br>
Planix, Inc. <<a href="mailto:woods@planix.com" target="_blank">woods@planix.com</a>>
Avoncote Farms <<a href="mailto:woods@avoncote.ca" target="_blank">woods@avoncote.ca</a>><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>