current status: writing a build system in cmake
-
@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
-
@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
-
@aismallard@woem.space @whitequark@social.treehouse.systems
cmake with classes
-
@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@woem.space @whitequark@social.treehouse.systems
cmake with classes
-
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 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. -
@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 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
-
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 I have described the Linux kernel's build system as "a build system implemented in GNU make," so, seems normal.
-
@pikhq @whitequark there are a lot of people for whom build systems are just not on their radar. I don’t understand them in the least, but I have definitely observed them in action.
