Tag Archives: build

Development, Open Source

Autotool alternatives

7 Comments

Lots of people whine and complain on the set of build tools we often refer to as a collective by the term ‘autotools’. That term tends to include autoconf, libtool and automake.

I think a certain amount of criticism is warranted against this family of aged tools that are unix-centric, have cryptic ways to control them (I think there’s a reason m4 macros  is not widely used…) and they are several independent tools with a tricky mix of cross-breeding.A build tool

The upsides include them being well tested, fairly well known, there’s a wide range of existing tests done for them, they work fine when cross-compiling and they support building out-of-source tree just fine.

But what about the alternatives?

I spend time in projects where the discussion of ditching autoconf come up every once in a while, as sure as that the sun will rise tomorrow. The discussion is always that tool Z is much better and easier to deal with and that everything gets shiny if we just switch. That Z is a lot of different tools that are available today, including CMake, scons, waf or cDetect.

The problem as I always see and why I almost always argue against Z is that autoconf is old, trusty, proven and I know it. The Z tool is often much newer, less proven, less peoeple involved in the project know Z, use Z or know how to customize it (since new tests will be needed and some tests will need to be changed etc). So even though Z is sometimes accepted as a testing ground in my projects, a year or two after the Z was accepted – unless I myself have accepted it and joined its efforts – Z has lagged behind to a point where it isn’t good anymore since I don’t know it and most people are rather fixing the traditional autoconf stuff. So we extract the Z support again.

But if we would never accept new tools we would never evolve, and yes indeed autoconf and friends have their share of flaws.

The question is of course when to switch – what kind of project in what development state etc – and which alternative that is useful for a particular project. Me being a developer primarily working with plain C and working with lowlevel code and libraries mostly will no doubt have a different view than those who use other languages, who do more “apps” or perhaps even GUI programming…

Can you help me point out good build system comparisions and overiews? I’ve tried to find good comparisions but I failed. Just about all of them are written by the authors of one of these tools.

My ambition is to create some sort of comparison document myself. I think the comparison could include autotools, cmake, waf, scons, cdetect, qmake and ant. Any more?

(I got triggered to write this blog post after my post to the trio mailing list on this topic.)

Linux

uclinux is weird

I do a lot of work on various types of embedded systems. Professionally I’ve been working more or less exclusively with embedded development since 1996 (pSOS, VxWorks, OS9000, etc) and privately I hack a lot on Rockbox. The embedded work of mine has grown to become pure Linux-based since around the year 2000.

I’ve worked with (embedded) Linux on more than 10 different chip families, using cores such as x86, AMD64, ARM9, StrongARM, XScale, PPC, MIPS, SH4, m68k, MicroBlaze, Nios II etc.

And this is what I’ve learned: uClinux is weird.

I’ll of course admit that the fact that uclinux is currently more or less integrated into the regular kernel development is a good thing and all, and even though I haven’t done much uclinux hacking with older kernels I bet things were worse before.

The problem with uClinux that I think is the major obstacle is their build system. Oh wait, perhaps the problem is actually two: the first being that they ship as an entire distribution with kernel and tools and stuff all lumped together instead of doing it like all the other embedded (real) Linuxes do: assume that people fix their kernel in one go and the entire rest of the user-land universe in a separate tree.

Anyway, what’s the actual problem is the build system. There’s no scattered Kconfig files that you’d expect if you based a build on that concept, and it is really hard to figure out where to poke to change a build to do what you want. Then, there’s a top-level make that take ages and runs through all sorts of hoops even when there’s nothing at all changed. Not to mention that it alerts about make -j “sometimes not working”. In a recent project of mine I learned that I usually had to run make twice(!) in the uclinux-dist directory to be really sure that the output image was correctly made!

Unfortunately, I’ve not been able to dig into this issue properly to work on or suggest proper fixes but I hope that I will one day. Of course a factor in all this is that many people (like the entire embedded Linux universe) use very old versions of the packages so fixes can have been made in the recent years(!) without them having yet get absorbed at many companies.

So the truth is: I do recommend customers to go “full”, “real” Linux not only for the powers a real MMU gives but also for the more mature and nicer build environments.