<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.<br>
</p>
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.<br>
<br>
For my own code, I stick with straight make, and the occasional
script.<br>
<br>
<div class="moz-cite-prefix">On 06/20/2024 02:00 PM, ron minnich
wrote:<br>
</div>
<blockquote
cite="mid:CAP6exY+pHTAoTHjZnDWcSLVcJXWxi4__cMVnCt7on1zEUC4Yzw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:gwoods@acm.org" target="_blank">gwoods@acm.org</a>><br>
<br>
Kelowna, BC +1 250 762-7675
RoboHack <<a moz-do-not-send="true"
href="mailto:woods@robohack.ca"
target="_blank">woods@robohack.ca</a>><br>
Planix, Inc. <<a moz-do-not-send="true"
href="mailto:woods@planix.com" target="_blank">woods@planix.com</a>>
Avoncote Farms <<a moz-do-not-send="true"
href="mailto:woods@avoncote.ca"
target="_blank">woods@avoncote.ca</a>><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>