| I agree with you to a degree, but I frame it slightly differently because there is a solution. The problem is one of Tooling & Methodology. Not just tooling. There is no divide between tools/methods - although there is often a massive conflict over methods, and thus tools, implying a relationship - but in fact both tooling and methodology need to be aligned or else poor tools are created. There is much discussion about ‘the build problem’, but it is just as much an issue of solving ‘the method problem’. For example, a vast majority of the problems of building software can be solved by using Docker (a method), or indeed adding new methods for various situations - i.e. embedded: compiler-onboard vs. cross-compiling, games: —march, etc. I think the “I and Your” part of your position is ineffective - better to think of it as ‘a tool I/others want to use’ and ‘a method I/others agree to use’, where: tools and methods are aligned in equilibrium for the duration of the project (in an ideal case). It’s ineffective because of the difference in effect between ‘want’ and ‘agree’ on that equilibrium. Some methods, a person may not necessarily want to use - but agree to do so, because there is a local tool to assist with the method. Some tools, people will violently refuse to use because they despise the implied method and will never agree to it; sometimes, people get fired for not aligning methodology - but also often for writing a tool nobody (or hardly ever anybody) ever uses/can use/wants to use. (There’s a whole world of software that only one guy knows how to wrangle because they ‘built a better build system’…) Apropos the “Yet Another C/C++ Configuration/Combobulator” problem, I tend to think the ‘problem with build systems’ is due to the avid desire to just build a new tool to force a new method rather than adopting an existing method and thus using existing tools, and, therefore in my opinion, the fewer new tools in this department, the better… but that’s just me, I’ve been wrangling C/C++ codebases since they were new languages, and I’ve seen some shit, kids .. The solution is _always_ to align your methods with your fellow user-developers first and then work together on the tooling, old or new… because all software is social, and has a social responsibility to the user, and user-developer tools built to construct software socially, even more so. |