People are afraid of running unaudited `curl | sh`, but nobody bats an eye on 24707 lines of obfuscated garbage in `./configure`.
@kornel people also run "ofuscated" executables
@bagder Sure, but risks of binaries are rather obvious.
./configure seems to have flown under the radar due to counting as “source” despite not being much clearer than a decompiled binary.
To me this is such an unnecessary risk. It’s a slow awkward build system, and the reason it’s like that is due to its only unique selling point: support for platforms so obscure that museums don’t even keep them on display.
@kornel but that's just your opinion and frankly, there are no alternatives without at least a corresponding set of (other) flaws
@bagder I know. It’s incredible that this should be a solvable problem, and yet C only has variously problematic build systems, and chronically terrible dependency management.
To me the most depressing thing is that has always been like that, and there is no hope of it ever getting better, because in C time has stopped in 1989.
@kornel and at the same time, none of the new fancy languages can do system libraries proper with dynamic linking etc. Which C solved already before 1989.
@bagder Dynamic linking is entirely orthogonal to this, and it's not C vs other langs. It's C being unable to fix anything.
Most autotools tests should have been compiler features, or standardized to remove pointless fragmentation. But in C it's impossible to fix even smallest problems on a timeline shorter than a decade or two, status quo is accepted as that just how things have to be. Often there is no will to even try, because it won't be compatible with C89.
@kornel I disagree with just about all of that. As you probably could've guessed.