Comment by adev_ | Hacker News Reader

Comment by adev_ | Hacker News Reader

Parent Full thread

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software.

I will be mean, I am sorry but this kind of attitude piss me off.

If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. Whatever the language and the build system.

These "dumpfires" have been able for 20 years to build program scaling from 10 lines to 100M lines... On platforms that are maybe older than you (AIX, HP-UX...) and ranging from micro-controlers of few KB of RAM to the biggest supercomputers in the world... They work for for kernel mode and user mode... and are also able to build an entire OS distribution like OpenBSD.

They are indeed not perfect.... but they deserve at least a little bit of respect, even from the script kiddies not able to understand them.

And honestly, an other point where Theo is right: I bet that none of their (your) '3.0 Modern successor' will be able to replace them in the next 15 years.

The reason most of these things aren't replaced is sheer inertia. You're asserting they got this position due to merit. I assure you, spend any appreciable amount of time working with Autotools, or any of the "traditional" Unix build systems, and you'll find their success in large open source projects is only due to

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.

> 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

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

"If you are not able to run a ./configure / make / make install & 3 apt-get properly."

Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.

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

You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me.

But keep calling people "script kiddies" that's cool.

> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me.

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.

> I am curious of your notion of "gatekeeping"

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.

> enjoy some arcane technical artifacts

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.

Speaking as a C developer of twenty or thirty years or so who's used make for all that time:

Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.

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

I think there’s a difference between being able to use make and ending bale to understand make. My suspicion is that most people can’t understand the makefile for a project they didn’t write or spend significant time on.

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

Understanding make is the easy part.

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.

Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead...

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.

> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead...

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.

> The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make.

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.

Yes! It’s ridiculous how modern languages all try to do package management too, and how they’re all mutually incompatible.

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.

Reply on news.ycombinator.com