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,

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)

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

@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