✧✦Catherine✦✧May 11

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)"

Show thread✧✦Catherine✦✧May 11

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,

Show thread✧✦Catherine✦✧May 11
hasn't read the book / has read the book
Show thread✧✦Catherine✦✧May 11

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)

Show thread✧✦Catherine✦✧May 11

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)

Show thread✧✦Catherine✦✧May 11

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

Show thread✧✦Catherine✦✧May 11
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
Show threadnadja

@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)

May 11 at 8:31pmWeb
Show thread✧✦Catherine✦✧May 11

@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

Show threadnadjaMay 11
@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.