<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I think there is a parallel to the systemd discussion here,
again. Both CMake and systemd ask you to declare properties or
qualities to be ingested into the abstract model of the build or
init problem, that is their worldview, and then, the 'engine' will
consume that and decide what to do and how to do it. Whereas init
scripts and makefiles say exactly what to do when, and the
abstract model of what is to be done is in the mind of the author
of the build or the init process. Makefiles and init scripts are
prescriptive, Cmake and systemd input are descriptive.<br>
</p>
My problem with CMake has been that the abstract model that the
CMake engine has in mind was not docmented, to my satisfaction, or I
couldn't find the answers to questions I had. The 'algorithm' was
not published, so to speak, or I couldn't find it. Unless I read the
CMake code and can understand it well enough to predict what it will
do. Maybe CMake aficionados do just that, I don't know. To me, both
systemd and CMake seem much more opaque and mysterious. If I have to
read the code for a tool to use it effectively, that seems wrong to
me. Maybe I just haven't read the right books. Is there a 'nutshell'
or similar book for CMake ?<br>
<br>
These tools seem to have more complexity, and a different mission,
then /etc/rc or sysvinit scripts, or make. They are designed to
solve a problem that isn't a problem to me. I expect a little bit of
human attention to maintenance is required, for the actual problems
I face, not all possible problems, so that I could theoretically not
ever know how to solve those problems, because the tool would have
done that for me. If I could only learn the dark art of that tool.<br>
<br>
<div class="moz-cite-prefix">On 06/18/2024 08:14 PM, Luther Johnson
wrote:<br>
</div>
<blockquote
cite="mid:f72ac02c-d28c-435a-9b03-64118ae232da@makerlisp.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<p>To be fair, makefiles are specifications in a build-tool
specific language. But it is one language I already know, and it
is one that seems to be well-formed, translates to very definite
actions on conditions, and I get to choose those actions. I
guess it works for me if I do my part, and I can't really see
what CMake does for me that I can't do for myself.<br>
</p>
<div class="moz-cite-prefix">On 06/18/2024 08:07 PM, Luther
Johnson wrote:<br>
</div>
<blockquote
cite="mid:a6e1b2d5-f52b-0365-1b73-6844d18e3c6f@makerlisp.com"
type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<p>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.<br>
</p>
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.<br>
<br>
<div class="moz-cite-prefix">On 06/18/2024 05:46 PM, Nevin Liber
wrote:<br>
</div>
<blockquote
cite="mid:CAGg_6+P8h+czyXx0uxPDSJKUtWsMjsbD6ZGwJtHDbmiFvgxFTw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr">On Tue, Jun 18, 2024 at 7:09 PM Luther
Johnson <<a moz-do-not-send="true"
href="mailto:luther.johnson@makerlisp.com">luther.johnson@makerlisp.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
agree with Greg here. In fact even if it was well done,
it is<br>
declaring something that wasn't really a problem, to be
a problem, to<br>
insert itself as the solution, but I think it's just
extra stuff and<br>
steps that ultimately obfuscates and creates yet more
dependencies.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>But I'll bite. There was the claim by Larry McVoy
that "Writing Makefiles isn't that hard".</div>
<div><br>
</div>
<div>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.</div>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div> Nevin ":-)" Liber <mailto:<a
moz-do-not-send="true"
href="mailto:nevin@eviloverlord.com" target="_blank">nl</a><a
moz-do-not-send="true" href="mailto:iber@gmail.com"
target="_blank">iber@gmail.com</a>>
+1-847-691-1404</div>
</div>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>