[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Luther Johnson]

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 at makerlisp.com <mailto:luther.johnson at 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 at eviloverlord.com>iber at gmail.com
> <mailto:iber at gmail.com>>  +1-847-691-1404

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240618/45ed3343/attachment.htm>