4 ms·
The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(
by munificent 2y ago
The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(
- dgfitz 2y agoThis means the architecture is also bad, and that is what needs to be fixed.
- almostgotcaught 2y agoso simple huh? since you fancy yourself an architect can you let me know how we might fix the architecture of https://github.com/llvm/llvm-project https://github.com/llvm/llvm-project such that CMake is no longer needed?
- dgfitz 2y agoNot in a glib response, no.
- almostgotcaught 2y agookay can you at least tell me how the architecture of https://github.com/llvm/llvm-project https://github.com/llvm/llvm-project is "bad"?
- db48x 2y agoThat’s such an obnoxious tactic. It’s basically saying “Your point is invalid unless you can cut this Gordian Knot on the spur of the moment in an internet comment!”
- philipwhiuk 2y agoIt's less bad than the ill informed Dunning-Kruger opinion it rebuts.
- troad 2y ago>> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn't stop existing. >> With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes. >> Complexity has to live somewhere. If you embrace it, give it the place it deserves, design your system and organisation knowing it exists, and focus on adapting, it might just become a strength. - Fred Hebert, https://ferd.ca/complexity-has-to-live-somewhere.html https://ferd.ca/complexity-has-to-live-somewhere.html
- lmm 2y agoI think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental. And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically means worse performance). Worst case if I need to do something complex at build time I'd rather model that as "the build system invokes a program that does something complex" than try to express the complex thing in some Turing Tarpit "configuration" language.
- globular-toast 2y agoAlso the point of software engineering is to take the real complexity that actually exists and you can't get rid of and work out how to write simple code to deal with it. Good software architecture does not include complexity because there is complexity in the business. It manages the complexity with simple code. The trouble is when people say "complex" you don't really know what they mean, though. They often just mean "difficult". Every programmer who wants to use that word needs to watch this: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
- PhilipRoman 2y agoAfter seeing enough bitbake recipes, I have to respectfully disagree. Some things are better off left unbuilt.
- dgfitz 2y agoI wish I’d included this in my initial response: I am painfully aware of bitbake. I’ve probably written 3-400 recipes. Most of them are about 20-30 lines long, because I refused to hide the compilation mess inside a recipe. I fixed the problem _before_ getting to the bitbake part. Most of my recipes at this point need only a repo name, the recipes are identical after that.