It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do.
I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.
"Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.
The problem is installing 206 different pythons on my system just makes it more likely that something else is going to break.
ISO9001 often turns into its Dilbert parody of bureaucracy, but the core ideas are sound: if you have some sort of failure of production, it's useful to know what went into the production process and where it came from. So in the case of deploying images, then yes: you get repeatable copies of the image. Provided you know where the image came from. Images themselves aren't usually stored in a version control or configuration management system. It may not be obvious where the image came from. And, if an image is made up of numerous "parts" (ie all the installed software), you need to know what those parts are. If an SSL vulnerability is announced, what is the process for guaranteeing that you've updated all the master copies and re-imaged as necessary?
A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.
The same reason people prefer to use garbage collected and dynamically typed programming languages.
It is merciful that GUI environments are immune to these deficiencies.
Which is why there's alternatives – cmake, waf, …
Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...)
Personally I like make. I understand it. I've used it for something like 20 years now. If there are problem domains it doesn't work for, they aren't problem domains I encounter. (Like so much of Linux software in the past 5 years or so, I find myself saying "this seems like an interesting way to solve a problem I simply don't have".)
Each their own poison. Personally I don't like them either, but pretending it's autoconf or curl|sh is an oversimplification.
While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover.
It doesn't excuse it - but I think it's easy to see why people turn to curl | sudo bash as the author puts it.