19 Jun
2024
19 Jun
'24
9:36 a.m.
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.
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 ?
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.
On 06/18/2024 08:14 PM, Luther Johnson wrote:
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.
On 06/18/2024 08:07 PM, Luther Johnson wrote:
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 PM Luther Johnson
<luther.johnson(a)makerlisp.com <mailto:luther.johnson@makerlisp.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. 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 <mailto:nl
<mailto:nevin@eviloverlord.com>iber@gmail.com
<mailto:iber@gmail.com>> +1-847-691-1404