Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: