5 ms·

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 cr

by cbsmith 10y ago

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

cpeterso 10y ago
Do we still need autoconf in 2016? Systems are becoming more homogeneous with the spread of Linux, GNU, and common programming conventions.
- swolchok 10y ago
  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.
  - cbsmith 10y ago
    > 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.
- cbsmith 10y ago
  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.
- jbk 10y ago
  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.
phkamp 10y ago
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.
- emmelaich 10y ago
  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)
  - cbsmith 10y ago
    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.
    - emmelaich 10y ago
      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.
  - cjg_ 10y ago
    Well, those binaries still needs to get built somewhere, so the makefiles, patches etc still need to live somewhere.

by cbsmith 10y ago

cpeterso 10y ago

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

swolchok 10y ago
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.
- cbsmith 10y ago
  > 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.
cbsmith 10y ago
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.
jbk 10y ago
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.

phkamp 10y ago

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.

emmelaich 10y ago
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)
- cbsmith 10y ago
  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.
  - emmelaich 10y ago
    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.
- cjg_ 10y ago
  Well, those binaries still needs to get built somewhere, so the makefiles, patches etc still need to live somewhere.