I’ve been thinking about build systems a lot this week, thanks to V8’s terrible use of scons, its replacement, gyp, being a broken pile of steaming still, and everyone’s collective hatred of autoconf.
I think Guru (vaporware with a good idea) is onto something, though.
I think a lot of build systems are too process-focused, which is exactly the path that leads to platform dependence and the craziness that’s come before.
If each module declares what it should know about the process, that’s a start: main.c knows that it’s the entry point of a program. It can say so. foofuncs.c knows that it’s the implementation of the functions defined in foofuncs.h, but it doesn’t know whether it’s destined for a static or dynamic library, or even just #includeed into other code. It can declare the parts it knows about.
Then, there can be module-level declarations: “These things form a coherent library”, “These parts are required for feature frobnicate”, “this must be linked with library having function foo”
Then at the package level, one has to configure major options – are we installing in an application specific root, or a system-wide one? Are we building full-featured or light? Cover-your-ass static linking of everything for a build that works everywhere, or shared-everything to play nice with the specific system being installed.
What do you want a build system to do, and more, not do?