> 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.
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.