Hacker News Reader

Comment by phkamp | Hacker News Reader

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com