current status: writing a build system in cmake

not "something that builds a project and is also implemented in implemented in cmake"

no, it is "something that is implemented in cmake and can be used to implement a build system that is in turn used as a part of a build system (also in cmake)"

@whitequark

You... choose to do that?

Blink twice if you're under duress.

i'm making it sound more complicated than it is, the actual thing boils down to "cmake's dependency resolution algorithm doesn't work for a particular edge case i'm having, so i'm implementing a different one, in cmake script"

but also "dependency resolution algorithm" is basically what a build system is, so,

hasn't read the book / has read the book

@whitequark We live in a broken world.

@grumpybozo it's an improvement on "a simple Makefile" that i'm replacing (it's so "simple" that it has several instances of load bearing rot13. not a joke)

i don't know if the fact that doing this is somewhat normal in a certain type of cmake project makes it better or worse

(compiler component dependencies are sometimes handled this way. LLVM has a much more elaborate system that boils down to the same thing. they also let you interact with it out of tree, which mercifully i don't have to care about)

@whitequark which book?

@solonovamax the meme i'm obliquely referencing was about GoT red wedding

@whitequark lolz

@whitequark That must be the most masochistic tech project short of installing Window ME.

Now I wonder what you're up to next :)

@x42 in something like 2019 i tried to improve the "simple makefile" that this project used to have and it damn near gave me a psychotic break after i stared at it for three days. believe me, meta-cmake is an improvement

@whitequark checks out

@whitequark

The world of buildsystems is weird and fascinating.

My opinion on cmake is that (for certain domains) it's the best there is, and that's sad.

@whitequark Any sufficiently complicated Cmake project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a working build system.

to be clear i'm not doing this because i love writing cmake syntax that would drive mere mortals mad. i do it because i'm replacing a "simple Makefile" that has perhaps once fit that bill, but eventually turned into a 1200-line (not including *.inc files) monstrosity with a load-bearing rot13 call inside of a manual reimplementation of half of git submodule

(this particular monstrosity has since been removed but the overall genre has not changed)

every time you run make it executes so many $(shell) calls (there are 40 of them, though some would be ifeq'd out) that it takes more time to create a dependency graph than to incrementally compile and link one compilation unit*

* if you use lld and split-dwarf, but still

this sort of thing is why when i see a project advertising "a simple Makefile, none of that [build system the author hates]" i see red. simple is in the eye of the beholder. and more often than not i have to patch the damn thing to make it cross-compile at all

@noisytoot i think it was trying to grep itself but without hitting the grep call, or something similarly unhinged

@whitequark Catherine is just doing build system freediving again

@chrisvest @whitequark what an amazing turn of phrase, thank you for this

@SnoopJ @chrisvest i have been using this project for more than half of my career

@whitequark Gah. This, this, this. I like having Makefiles or similar to capture blessed ways of invoking build systems, but yeah, there's a reason build systems exist, ffs.

@xgranade @whitequark developer looking at essential complexity: I can remove this accidental complexity

@whitequark every succesful Makefile-driven project I've seen is in fact a complex Makefile

@whitequark or i suppose a more accurate way of looking at it, is it seems the Makefile complexity scales with project complexity, and if it is not doing that then there is probably something fragile about it you're not seeing

@whitequark the lua interpreter, for example, 450 lines of Makefile. and that's plenty enough to cross compile, build on a wide array of OSes, and even target microcontrollers like on my Nintendo DS. Good example of a simple project with a simple Makefile

xD

@whitequark This is why I really enjoy the sentiment behind shake. Because sometimes when it comes to build systems the “simplest” solution means giving the developer access to all of Haskell and telling her to go nuts :D

(Not saying shake is a good general solution for build systems. It very much isn't. But it beats the bundle of legacy makefiles that could legally drink in most of europe 9 times of 10)

@whitequark oh lmao I think I know what you're talking about, and I think I touched that rot13 monstrosity at one point

@dequbed I haven't used shake but I did use ocamlbuild and the other thing I forget the name of, and it was somewhat preferable to some of the makefiles

dune (a declarative ocaml build system) is way better though

@whitequark I like Shake because it's very good about using the ability of Haskell to create ad-hoc declarative DSLs to give an user a very declarative toolkit while having an escape hatch *right there*. But I have used little of the alternatives either, I rarely have to fiddle around in the bowels of complex build processes and I'm very glad about that.

@whitequark yeah, for every well-designed makefile that works on every system of relevance and is easy to maintain there are maybe a thousand absolutely _terrible_ ones which you can't maintain well, lack fundamental features, and make me wonder if the developer knows what they're even doing

@whitequark c²make

@whitequark a load bearing WHAT again?!

@whitequark The culture of "it's nearly free to fork and exec" is wild. Got us autoconf too, I guess

@recursive my solution to this was to use kati, google's make with a ninja backend

technically this probably caused some sort of staleness somewhere in the system but it was so much faster when i needed rapid iteration that it was totally worth it

@whitequark coworkers of mine several years ago changed our forked 'premake' (some lua thing) from generating makefiles to ninja files, and it seemed like a decent thing to target with automatic generation

@recursive oh yeah ninja is excellent. not just the software but the specification, which is one of the few emergent ones that are just good somehow

@recursive ninja files are basically what makefiles should have been, easily parsable, mostly declarative dependency graph descriptions without the bewildering mass of features that accumulates if you also try to shoehorn an UI into it

@aismallard @whitequark

cmake with classes

@arcterus @aismallard aaa

@whitequark ah, the fingerprints of an engineer who is very capable, but doesn’t bother to read the docs or think about alternatives…
I’ve reimplemented a git LFS client without knowing that’s what I was doing.

@c0dec0dec0de oh man that's kinda impressive. i once considered implementing a git LFS client while knowing exactly what i'm doing and figured i really don't want to do that

@whitequark I mean very minimal. Like it fetched the bits I needed. “God, why are these binary files just a sha hash? Oh, and there are files over here with those hashes as names, fine, let’s do this.”

@whitequark self-awareness is not always online

@whitequark someone wrote a raytracer and PNG encoder in CMake sooo

@whitequark

What happens if we remove all the abstractions? That will make everything simpler!

@whitequark Now I’m curious what the edge case is!

@whitequark @grumpybozo What is the rot13 for?????

@whitequark @grumpybozo More seriously, have you considered using Shake? It’s a Haskell eDSL, so I would expect it would support just about anything one needs.