Hacker News Reader

Comment by cratermoon | Hacker News Reader

I built rn on a number of different systems at the time, and I was fascinated by the configure/build's messages while it tried to figure out what os & hardware it was running on.

Also "This program posts news to thousands of machines throughout the entire civilized world. You message will cost the net hundreds if not thousands of dollars to send everywhere. Please be sure you know what you are doing."

View on HN

I was kinda excited when I first saw autoconf. In the "good old days" porting software that academics wanted on the local Unix box was a genuine exercise. When you see all the differences that the "configure" command comes up with it gives a little twinge of nostalgia for when even things like the version of libc available wasn't in the expected place. Trying to get stuff running on an Apollo or a DEC 3100 or a Pyramid was fascinating and frustrating at the same time.

I remember this too. First year of university in 1991, me and my friends who'd all gone to different places used to write actual letters on paper and post them to each other. I was on the internet for the first time, and was excited to be able to download pictures! I could print them out and include them in the letters. If I remember correctly I needed to compile some kind of image viewer/manipulator on my account on the DEC Mips machine we CS students had access to. Anyway, as you say it was amazing watching the autoconf script feeling its way around and discovering its environment.

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.

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.

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.

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

Reply on news.ycombinator.com