current status: writing a build system in cmake
-
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)
-
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
makeit executes so many$(shell)calls (there are 40 of them, though some would beifeq'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
-
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)
@whitequark Catherine is just doing build system freediving again
-
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)
@whitequark what is it using rot13 for? -
@whitequark Catherine is just doing build system freediving again
@chrisvest @whitequark what an amazing turn of phrase, thank you for this
-
@whitequark what is it using rot13 for?
@noisytoot i think it was trying to grep itself but without hitting the grep call, or something similarly unhinged
-
@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.
-
@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 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 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
(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)
-
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)
@whitequark oh lmao I think I know what you're talking about, and I think I touched that rot13 monstrosity at one point
-
@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
(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)
@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
-
@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.
-
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)"
-
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)
@whitequark a load bearing WHAT again?!
-
every time you run
makeit executes so many$(shell)calls (there are 40 of them, though some would beifeq'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
@whitequark The culture of "it's nearly free to fork and exec" is wild. Got us autoconf too, I guess
-
@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
-
@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
