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

[Luther Johnson]

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 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/370bff76/attachment-0001.htm>