No, ofc nobody wants to do that and that's not really what I'm saying. I'm saying that all current build tools suck and can only ever decrease your software's value and decrease productivity.
Let me illustrate. Your software is a product X. It has some value V (as by some measure of value, perhaps $ earned). The product X is the ultimate output of some build tool T.
Now image you had this incredible build tool that produced X without any programmer doing any build related work ever at all. Your build output is X and value is V. 100% of your developer effort can go towards working on X and increasing V!
Now in reality you spend some amount of time writing build files, working with the build, fixing bugs in the build files, generally maintaining it. This is typically non zero effort and the cost grows above linearly wrt respect to build configurations/platforms supported etc.
However the output of the build tool is still the same X and value is still V. So your build tool added 0 value!
In fact any build tool can only ever decrease your product's value. Why? How? Because of the cost of messing with the build is non-zero and you spend time on it that could otherwise be spent working on actual things that produce more value (such as adding new features or fixing bugs or whatever). i.e. you can only put 100% - "build effort" amount of effort towards working on X and increasing V.
> Now image you had this incredible build tool that produced X without any programmer doing any build related work ever at all. Your build output is X and value is V. 100% of your developer effort can go towards working on X and increasing V!
That is only the case for the simplest of software though. "Build systems" are often much more than just build systems: they are project management tools.
e.g. quite often I have to perform some preprocessing or code generation.
I could :
- A: write a $cross_platform_scripting_language script and integrate it to my build system & CI, ensure that the script interpreter is correctly found, that the build dependency graph is correct, etc etc. But just getting the same version of python to work reliably on 5+ different platforms is already quite a pain.
- B: write the preprocessor directly in my build system language (in my case, most of the time CMake).
Option B takes wayyyyy less time in my experience than option A, even though it looks more "build-related" than option A.
Right like I said some build tool can improve your productivity wrt to some other build tool. But did it create any absolute value in the end product?
Let's say you first build your product with autotools and you sell it for X$ per unit. If you later port your application to CMake. What value does CMake create in the end product? Can you sell it for more than X$ on the basis of having been built with Cmake? Usually no. The build system created 0 absolute value gain. You can claim that oh.. CMake is simpler than autotools and will save some time in the future thus creating a gain relative to autotools. Yet it's not capable of generating absolute value added. In absolute terms every build tool can only retract effort away from the activities that produce the value, i.e.software features.
> What value does CMake create in the end product? Can you sell it for more than X$ on the basis of having been built with Cmake? Usually no.
That is true for every technological choice.
> In absolute terms every build tool can only retract effort away from the activities that produce the value, i.e.software features.
Again you seem to think that build systems don't contain software features. I don't think that this is true. My build system helps me to refactor things that I would have to do by hand otherwise, and which are pretty project-specific. For instance scanning subprojects for their license information and generating a .cpp with that info, looking for all uses of a particular token and listing the files using that token for them to be included somewhere, etc etc.
Let me illustrate. Your software is a product X. It has some value V (as by some measure of value, perhaps $ earned). The product X is the ultimate output of some build tool T.
Now image you had this incredible build tool that produced X without any programmer doing any build related work ever at all. Your build output is X and value is V. 100% of your developer effort can go towards working on X and increasing V!
Now in reality you spend some amount of time writing build files, working with the build, fixing bugs in the build files, generally maintaining it. This is typically non zero effort and the cost grows above linearly wrt respect to build configurations/platforms supported etc.
However the output of the build tool is still the same X and value is still V. So your build tool added 0 value!
In fact any build tool can only ever decrease your product's value. Why? How? Because of the cost of messing with the build is non-zero and you spend time on it that could otherwise be spent working on actual things that produce more value (such as adding new features or fixing bugs or whatever). i.e. you can only put 100% - "build effort" amount of effort towards working on X and increasing V.