Hacker News Reader

Comment by ggm | Hacker News Reader

I wasn't. I have always felt autoconf was the wrong solution because it gives in to the problem.

Uname -a having a build hash, and an index of hash to settings would have done better. Think of all the wasted CPU cycles computing how this chip orders a long long and testing POSIX compliance one function at a time.

Autoconf only fixes the apparent problem. Not the underlying disease.

At least X11 tried encoding the known patterns.

View on HN

> uname -a

so whenever you upgrade the kernel or change CPU all your programs need manual patching? you may answer, "well uname -a was a joke, you would actually check the libc version". this worked alright in a very specific time period with a couple of big vendors with nigh-unmodifiable toolchains with well-defined release versions. it became increasingly awful when people started making their own toolchains with free software and had to patch every single piece of software to properly detect their new libc. sitting through an hour of autoconf sucks, but slogging through ten hours of patching poorly written bespoke configure scripts is a hundred times worse.

edit: not to mention cross-compiling where you can't even run uname -a, and which was almost universally broken before autoconf, which, despite being painful, made cross-compiling mostly work everywhere.

That would move a lot of work onto whoever first stumbled against a new combination. The magic of autoconf, when it works correctly, is that you don't have to have a configuration that has been seen before.

I can't count how many times I end trying to run autoconf only for it to tell me I have the wrong version of autoconf.

This is a general problem with modern SW. You always need the right version.

Hindsight is 20/20.

It's not that it can't be done, it's that the community went in a different direction, and there's a strong cultural bias. Bell Labs internally had a "new make" written by Glenn Fowler, that went full bore into tracking dependencies, probing local and global resources, recording configuration state at build time, that we adopted in Graphviz. It was powerful and concise. It was also a heroic effort for Glenn to maintain and develop, though others were assigned. https://ieeexplore.ieee.org/document/6771042

At one point in our project we had a lot of arguments about build systems and software repositories (there were times when we had to stop talking about it), then at some point John Ellson said, look, everyone else is using autotools, so do you want them to use your software? We realized he was right.

Individuals in the software community are capable of building a lot of amazing tools. The difficulty is persuading the community and teaching non-specialists to use them. They already know how to run make, or ./autogen.sh; ./configure --prefix=$HOME

Despite this Graphviz still has 3 or 4 build systems: autotools, Visual Studio (probably 90% of our audience is on Windows though we try not to think about it), Xcode (needed for an under-maintained MacOS app), and Magnus Jacobsson and Matthew Fernandez have a lot of a Cmake build working, though not yet complete.

Apologies for rambling a little off topic.

If there's one thing you never have to apologise for on HN it's going off topic into trivia like this.

That's true, now we can go back and simplify, I was more speaking to the origination of all of these horrible things. Nobody knew when they picked 2048 instead of 1024 it was going to matter, but then suddenly it did and nobody wrote down a good way to probe that API.

Reply on news.ycombinator.com