current status: writing a build system in cmake
-
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
-
hasn't read the book / has read the book
@whitequark lolz
-
hasn't read the book / has read the book
@whitequark which book?
-
@whitequark which book?
@solonovamax the meme i'm obliquely referencing was about GoT red wedding
-
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 That must be the most masochistic tech project short of installing Window ME.
Now I wonder what you're up to next
-
@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 Any sufficiently complicated Cmake project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a working build system.
-
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.
-
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)
