Comment by cbsmith | Hacker News Reader

Comment by cbsmith | Hacker News Reader

I still hate this essay as much as I did when it first published it. It misunderstands the problems.

Unix was fragmented long before 1991, when autoconf was created. Prior to autoconf, Perl's Metaconfig did this dance, and a lot of other, lower quality systems like imake were used to work around the problem. The forces behind Unix's fragmentation was actually not the Bazaar (open source software), but attempts by multiple parties to independently build their own Cathedrals (in attempts to differentiate/provide value with proprietary systems). Of course, autoconf, as a GNU system, was, in Cathedral & Bazaar terms, a Cathedral, not a Bazaar.

Autoconf is ugly/copy-paste code because it is comparatively rarely run, so as long as it produces a passable result, people use it and focus their efforts on other, bigger itches.

There's also a long history of open source products which have enjoyed higher quality implementations than their proprietary equivalent. The Apache project itself stood as a higher quality web server than a lot of other choices (not as true today, but it was true for quite some time).

One could go on...

I think you misunderstand my essay.

Yes, autoconf was clearly a response to the incompetence of the UNIX industry, were everybody thought they could become Da Man over everybody else.

But that doesn't mean that it was the right solution then, and it certainly is not the right solution now.

And autoconf is absolutly nothing like a cathedral: There is no archtectural vision, no economy of style, no consistency and absolutely no symmetry or simplicity.

Your argument that "autoconf [...] is [...] rarely run" is akin to saying "I only pee in the shower in the morning": That is of course better than doing it all the time, but it is still going to stink.

But really there are only two ways to deal with this. 1. make a better autoconf 2. avoid it as much as possible.

The first has been tried, many times and always found wanting.

The second - well, it's FreeBSDs fault using software 'ports' rather than prebuilt binaries. (Although I understand that you do that now)

It's not entirely true that a replacement for autoconf would just have to be a better autoconf. You don't need a solution that works at all like autoconf (doesn't even have to generate code at all). You can avoid MUCH of what autoconf deals with by writing portable code and following some sane strategies for constructing include paths and selecting library files. It's just that when you do that, you have to solve all of these problems yourself, while the autoconf library has already been battle tested on a wide variety of platforms... a level of effort that would be hard to replicate.

Agreed, well said. I didn't mean a literal better autoconf, I meant that the attempts to replace it have rewritten the problem to a lesser, simpler one.

Well, those binaries still needs to get built somewhere, so the makefiles, patches etc still need to live somewhere.

> But that doesn't mean that it was the right solution then, and it certainly is not the right solution now.

I'm not saying it was the right solution, but the essay makes a lot of claims beyond some straw man notion that autoconf is the right solution. Even in my critique I made it clear that autoconf is inevitably NOT the best solution.

> There is no archtectural vision, no economy of style, no consistency and absolutely no symmetry or simplicity.

There's a distinction between autoconf & the autoconf library. Autoconf itself has a comparatively simple design that was conceived and implemented largely over one summer by one engineer, who curated it through several subsequent iterations of embellishments. It's design was extended in to automake, etc. which lead to the whole GNU build system.

The automake library on the other hand is largely a Bazaar of contribution of work arounds from developers, with some modest efforts at curation that emerged over time, rather than being conceived from the get go.

> That is of course better than doing it all the time, but it is still going to stink.

It still might stink, but it is hardly the most important problem most people deal with, and the whole process functions well enough in the end, so the people with the expertise to make a better solution have other more pressing problems instead.

Been rethinking my response in an effort to be clearer.

> Yes, autoconf was clearly a response to the incompetence of the UNIX industry

I think the use of the term "incompetence" misinterprets the forces at play in a way similar to the original article. That interpretation leads to the Cathedral seeming desireable over the Bazaar, when I'd argue if anything the reverse is true.

Proprietary vendors have a vested interest in differentiating themselves from their competitors. While they have an interest in making it easy to get software on their platform, they also have an interest in creating barriers to that software moving off their platform. They also have limited interest in changing established behaviours in their platform.

The Cathedral model doesn't mean there is one Cathedral. It means that people build software as Cathedrals. This creates additional friction to adopting changes from outside the Cathedral. The Bazaar model does make it easier for fragmentation to take place, but it also makes it easier for established and widely accepted practices to make it back into the code base, and creating additional pressures to be consistent.

Autoconf's design is a workaround for the fact that there was no Bazaar for "ld", and still isn't. Like most workarounds, it is uglier than one can imagine. It's whole design was an attempt to exploit the strengths of the Bazaar to work around the horrors reinforced by the Cathedral model. It persists because it remains the best solution of any that was actually built, and it continues to evolve in response to changes to platforms and changes to best practices. One could easily imagine better solutions, but one has yet to materialize. If it would, I wouldn't at all be surprised to see the Bazaar gravitate to it.

But what is the right solution? "Everything should be the same, everywhere" is, unfortunately, probably not a workable answer.

(And I might respectfully suggest that if your answer involves "the incompetence of [everyone else in] the UNIX industry", you may be part of the problem.)

> But what is the right solution? "Everything should be the same, everywhere" is, unfortunately, probably not a workable answer.

As proposed in the paper, the solution would be to address the distinctive nature of shared libraries on different platforms in the platform's implementation of ld.

"Instead of standardizing how to do that across all Unixen—something that would take just a single flag to the ld(1) command..."

Hmm. Yes. But what if they standardize on something you, or Kamp, don't like?

Here's an anecdote for you:

When I was working for IBM in the mid-90s, the AIX/RS6000/PowerPC C/C++ compiler folks (in Toronto?) were justifiably proud of the code their compiler generated. But it had one peculiarity. It generated machine code directly, without going through an assembler. Oh, it could generate an assembly listing with -S, but the output wasn't syntactically valid. It couldn't compile the generated assembly.

This was a strongly defended position. "Why would you want to?" they said, "It's really hard to write good assembly for a RISC machine. Not many can do it."

These are the people who are needed to standardize things.

Now, at the time, AIX had a ridiculously complicated (but very flexible and featuriferous) dance required to build shared libraries. Using libtool is easier. I can hear the counterargument now. "You want us to hamstring our users? To just guess what they what they want to do, behind a single flag? Are you crazy?"

Fortunately, now, after Linux switched from a.out to ELF, I have been able to use "gcc -shared" to build all of the shared objects I've needed to. So, yay!

But I understand Kamp doesn't like gcc....

To be clear, I'm critical of the argument for many of the same reasons you are.

However, the counter argument is that libtool is an existence proof that there is a simpler cross-platform interface that developers can work with and generally prefer for making libraries & shared libraries. At the very least you can accomplish what it does.

Honestly, I think he's absolutely right that it is possible to correct the problem in ld, but it require orchestration of a lot of work that a) isn't a priority, because libtool already solves the problem "well enough" b) most platforms have little incentive to do so, and c) that's not the Cathedral in the Cathedral & Bazaar model.

Do we still need autoconf in 2016? Systems are becoming more homogeneous with the spread of Linux, GNU, and common programming conventions.

You could argue that autoconf sucks and clearly everyone should use your favorite build system, but you need something to do the job. Not even two systems running the same release of the same distribution are going to have all the same packages installed. I might have put a newer version of X in /usr/local. I might want to cross-compile. Even considering all Linuxes the same, I might want to build for x86, x86_64, MIPS (routers), ARM, PowerPC, or some more esoteric chip. Android has its own special problems, including a different libc. I might want to ship on BSD (which one?), OS X, iOS, cygwin, mingw, or that newfangled Windows subsystem.

> You could argue that autoconf sucks and clearly everyone should use your favorite build system

Well, in fairness, build systems often deal with a different set of problems.

People have been asking that question since forever. It turns out, the world is a lot less homogeneous than it seems. If it weren't, package managers & containerized systems wouldn't be such a big deal.

You've still got a fair number of processor architectures and instruction sets (at the very least, you've got all the x86 & x64 variants + ARM + Power + Sparq), and you've got some pretty significant variants on the OS front as well (Windows, Mac, Linux, Android, iOS... and that's not getting into the embedded platforms), and you've got all kinds of variants (still) in C runtimes, let alone differences above that level.

You might not perceive the ugly, because tools like autoconf are abstracting the problem away, and that's exactly why they are beneficial. There are much better ways to build portable software, but they require a lot more expertise, and believe it or not, autoconf means you need much less expertise to make software that runs on the broadest set of platforms.

I've got a friend, a very senior software engineer, whose full time job is a build platform that builds software designed to run on customer platforms (and this is for office environments, so a comparatively limited set of permutations)... and this isn't for a big company. That's the size of his job when he can take advantage autoconf.

There certainly are other ways to do what autoconf does, but being able to leverage a ton of work that other people have already done dealing with odd inconsistencies that come up with platforms is very hard to walk away from, even if it is done in an ugly fashion.

Unfortunately yes.

We compile VLC for at least 9 different OSes, and on some of them, for 8 platforms. Autotools is the only tool that does it correctly. It's a pile of crap, but there is nothing else that works.

Reply on news.ycombinator.com