I mean autoconf,
libtool, and friends, collectively the
GNU build system.
Man, they’re hard to understand.
I took up work on
mod_atom today for the first time in
a couple of months and it didn’t work and I didn’t understand why, and
eventually mucked around with the infrastructure changing file extensions from
*.slo to *.lo (I don’t know what either is)
and then the .la (don’t know what that is either)
finally generated a valid .so (ah, I know what that is).
I’ve noticed that whenever I get into trouble with this shit and ask
around, even on the httpd developer lists where you think they’d know,
everyone says things like “Oh, well, I don’t really get it either, you
but if you copy XXX...”
Paul Hoffman wryly suggested that the
world has only ever had one autoconf project, the rest are
cut-&-paste copies.
I have this horrible sinking feeling that I’ll never be able to declare victory on mod_atom until I actually figure it all out. Is it OK to feel sorry for myself?
Contributions
Comment feed for ongoing:
From: Nick C (Jun 18 2008, at 02:25)
No :-)
[link]
From: Justin Mason (Jun 18 2008, at 02:52)
Actually, I took the time to learn how autoconf worked, way back in the 90s.
It's reasonably simple to grok, once you get your head around the horrible
templating/macro language that is m4.
However, other people then built a whole new heap of turds on top in the form
of automake and libtool, which seem less useful/coherent, as far as I can tell.
[link]
From: Graham Hughes (Jun 18 2008, at 05:18)
There's a lot of whining and moaning about the GNU toolset that I look into and largely discount. The complaints about autoconf and its ilk are not in this category. I even understand M4 reasonably well, but I cannot figure out what autoconf is trying to do and, more to the point, how to prevent it. It sounds like you're having some issues with the relocatable object file stuff libtool does, which is black magic.
I'd love to believe there's some alternative to this, but I haven't seen it yet. There's a lot of half-attempts at solutions, and you can of course hitch your wagon to a project like Perl or Python that has had some years to figure all this junk out and just do it their way, but I know of no coherent actual replacements for the auto* series of tools, which is sad.
[link]
From: Noah Slater (Jun 18 2008, at 06:29)
I had to get my head around it when developing the new packaging for Apache CouchDB, and I wont deny that it took a few long nights of head scratching, but, once you're over the hill, it starts to make a lot of sense. A steep learning curve, but portability is Hard.
[link]
From: Rob (Jun 18 2008, at 07:14)
I'm glad I'm not the only one who has nightmares about autotools. There's a bunch of other ones there you can try, like cmake or scons. I haven't tried scons but cmake is much easier to use than autotools.
[link]
From: Simao Reis (Jun 18 2008, at 07:38)
Hi.
I found this online book by Jonh Calcote to be quite helpful.
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
[link]
From: Michael Schuster (Jun 18 2008, at 07:53)
I think the main architectural problem with the auto* tools is the fact that the compilation depends highly on what's installed on the compilation machine. This, IMO, is fundamentally wrong, as it makes it nearly impossible (or very hard, at least) to distribute ready-to-run software built that way.
KDE (www.kde.org) got rid of these tools for their 4.0 release (early this year).
[link]
From: Pierre Phaneuf (Jun 18 2008, at 08:54)
Justin Mason is right on the money, although autoconf itself is getting a bit long in the tooth. Writing portable makefiles when everyone has GNU Make now seems a bit silly (it used to be that it was useful so you could compile GNU Make itself when you were on Solaris!).
I'm not entirely sure of what Michael Schuster is saying? Would you want your compilation to depends on what is installed on some other machine, but that you don't have?
This ties in to how pkgconfig tried to help, but you could find yourself in a situation where your compile didn't work because it couldn't find a library, but pkgconfig assures you that it's in a particular location (sometimes it is indeed, but it's a 64-bit library and you're building a 32-bit binary, say). autoconf has (had?) this principle that what people (or pkgconfig) say isn't what really counts, what really counts is that it *works*. So in this case, autoconf would give it a try, see that it doesn't link, then act accordingly (fail the configuration, or do without that library).
Then the user does go on a hunt to figure out what the heck is wrong, but the thing is, usually it involves fixing an actual problem ("oh, I need the 32-bit libraries!"), not "fixing" the autoconf package.
It could certainly do a better job of helping with this, but hey, there's a log file, it has the exact file content, command-line used, and the error message that caused it to belive that.
You might want to take a look at Quagmire (http://code.google.com/p/quagmire/wiki/QuagmireHome), by Tom Tromey. He knows about those tools, having been involved with the autotools for a long time, and knowing full well their capabilities and limitations. It also requires not much more than GNU Make on the build machine, as opposed to other systems which require people to install more software, or have Python/Ruby installed (the latter of which might be a bit fairer, but if they require only that, your package will also carry an implementation of Make in that language, which could be a bit much).
[link]
From: Michael Schuster (Jun 18 2008, at 15:25)
Pierre:
"I'm not entirely sure of what Michael Schuster is saying? Would you want your compilation to depends on what is installed on some other machine, but that you don't have?"
that's not it. You don't want the resulting binary to depend on what non-default component you might or might not happen to have installed on your system, but which auto* happily pick up.
Michael
[link]
From: Dalibor Topic (Jun 19 2008, at 04:41)
You're probably asking the wrong people. What IRC channel is this effort taking place on?
[link]
From: Matthew Laird (Jun 20 2008, at 10:39)
Your timing as always in perfect. After two months of putting if off I too got back to my joys in exploring the world of Auto* tools for a project I'm working on. I had been close before, but there were still some last little details I couldn't quite figure out. Books and manuals all seemed to conflict each other.
But the book by Jonh Calcote was fantastic! Thank you to the poster of the link. I can't wait for the final chapters to be done, I'm sure they'll further illuminate those last few dark corners in the GNU Tool world.
It's a powerful tool, but cryptic is definitely the best adjective to describe it.
[link]