1. Actually being better than the hodgepodge of shell/sed/awk/perl/etc scripts that people used before Autotools came around
2. The massive amount of work done by people to fix all of the corner cases where Autotools didn't work
I think you're maybe looking at them with rose colored glasses. When you've spent hours trying to track down obscure, undocumented `./configure` options, dealing with vague linker and compile issues, implicit, circular or broken dependencies, buggy and arcane configuration scripts... I can go on and on and on about the problems of building open source software. Building things from source is a yak shaving exercise -- always chasing your tail. It's great when you're using a configuration that has been tested and mostly fixed up, but step outside of those parameters and it can be hell.
It's not that newer build systems don't have their own issues, they just try to address the historical problems that people have experienced from using things like Autotools for decades. You can scoff all you want, but no sane individual is going to use Autotools as their modern build system. They're going to use something like CMake, or Bazel, or their language's build system.
I totally agree with what you said. And I am not defending Autotools here. I would even advise any new person here to NOT use Autotools if they can and stick to something more modern ( CMake, Meson or other).
There is however many reason why C build systems are what they are (heterogeneity of platforms, multiples compilers, ABI, multiple standards and multiple build systems themselves to deal with) that many other languages do not have (or not yet ?).
And it would be good to understand that before calling them dumpster fire because they are not as convenient as your cargo install.
This is not helping and deeply counter-productive.
This is this kind of attitude that headed to the situation that we have currently : 100 build systems and even more problems because almost none of them took lessons of the past (Scons, Waf, imake, B2, QMake, qbs, etc, etc ).
Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.
I tend to name a "magic bulshit bloat tool" that will makes me download 350MB of crap to compile an 'hello world' a "godawful tooling experience".
We are all free to have our own definition.
But keep calling people "script kiddies" that's cool.
I am curious of your notion of "gatekeeping", because you are the one being funny here.
People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No)
If "today", with the unprecedent level of documentation you have on the Web, it is a problem for you to do so, then yes: you are indeed a bad developper.
I am a strong believer of "the show me the code" approach. It is easy to call all the actual tooling a "dumpfire", then show me a better one, or at least document in details what "a better" one would be.
Critics are easy and in this precise context, without arguments, they are just FUD or religious beliefs.
Repeatedly telling people that they're bad developers, should walk away from a computer, that they are "script kiddies", because they do not know or enjoy some arcane technical artifact. I call this gatekeeping.
Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry.
These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences.
That is not 'gatekeeping', there is no gate to keep here. I name more that fight laziness and understand your tooling.
Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.
Great. And you could be a developer for 40 years, if you do not precise why and how. This is your comment which is arcane bullshit and complete nonsense.
It’s nice that their is a stable convention, but it’s a shame that it’s so dated and is missing so many modern conveniences (mostly to do with dependency handling).
Manual dependency resolution is a tedious waste of time, no matter how well you understand what you are doing. It can and should be automated.
I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.
The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make.
Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration.
If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/) to go around them.
> And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently.
If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language.
I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers).
In our current world, every language is its own isolated island and making them interoperate is a mess.
I’m not so sure about language-specific build systems, though. Trying to set up a custom asset pipeline in most build systems is a pain, when they want you to shoehorn everything into a single language rather than just calling out to external tools and scripts (ideally including tools built as part of the same project!) Bazel gets this right.