pandora-build: autotools made better, faster, stronger
|Time:||10:30 - 11:15|
|Day:||Wednesday 20 January 2010|
|Location:||Ilott Theatre (Town Hall)|
The GNU Autotools are great. Ok, so most of you think that they are the spawn of the devil, and I really don't have the energy to convince you otherwise. Thing is, Autotools are pretty much the standard and all of the replacements still blow goats worse than Autotools do. The real question is, how can we use them effectively today, how can we make our build systems do everything we want them to do, and then - how do we do that without writing tons of m4.
Enter pandora-build. We already went through all of this in Drizzle. And then we applied what we learned to libdrizzle, and to gearmand, and to libmemcached. We're working on applying it to memcached itself. Thing is - re-applying autotools techniques between different projects really, really, really blows... especially when you consider that I'm the one who had to remember to apply that one new little m4 trick I learned across five other projects. So I refactored all of our stuff into a set of reusable autoconf macros that you can drop in to your project and go.
"What?" you say? "Standardized build system? Isn't that what the Autotools were providing in the first place?" Indeed. But the design of Autotools is to allow you to express any possible build environment you want, which means that it's by design extremely flexible -and that by design you still need to do a lot of work to achieve a simple hello-world style system.
Pandora-build has no such aims. We provide you with a few top level entry points with a modest amount of flexibility (five options at this time) and then we tell you how things are going to work. We turn on all of the flags you want. We turn on lots of flags you don't think you want, but actually do. We get gettext and gnulib inclusion right. We call things in the right order. It all... works!
Additionally, pandora-build is its own project, so you can contribute patches if you're crazy like me, or you can just install it and make it a build depend, or you can copy the darned files into your project (what we're currently doing)
We'll talk about a couple of things in the talk:
- Why we stuck with autotools and not other options
- 5 minutes of me picking on CMake, SCons and Jam
- What, exactly, pandora-build will do for you
- Why those things are a good idea
- How you can go about using pandora-build in your own projects
You will not learn any m4 in this talk. I may show you some m4 just to scare you into using pandora-build rather than trying to write your own.
You will not learn advanced autoconf or automake skills in this talk, although you might over beer later.
You will learn how to make your projects behave properly without learning any m4 or autoconf or automake. Hip hip, hooray!
Monty is a Free Software Hacker on the Drizzle project. Although he's a Python developer by preference, he's developed an odd affinity for C++ and more knowledge and skill with autotools than is recommended... meaning he spends all of his time fixing autoconf scripts of course. He lives in Seattle where he is a lighting designer and an Associate Artist with The Satori Group.