This Time Self-Hosted
dark mode light mode Search

Book Review: Autotools by John Calcote

You probably know how I feel about Autotools books given I actually wanted to write one, was mostly rejected, and ended up working on spare time on Autotools Mythbuster — which I really should write more on. Definitely the “Autobook” needed a rehash, that was obvious. The spot was taken not by me but instead by John Calcote, with his Autotools: A Practical Guide To GNU Autoconf, Automake, And Libtool — okay I’m a bit envious of that, but not excessively.

At any rate, No Starch Press has been tremendously kind and offered me a review copy – I did contact them to propose my guide as a book, and they did tell me they had a book already in the works.. John’s – which I accepted gladly. I actually hoped to post the review much sooner, but between job tasks, and Gentoo messes, time was a rare commodity. And to be honest, it felt a lot like reading a textbook when you know already the subject. Don’t get my tone wrong. I find John’s work very stimulating: for a newcomer to the world of build systems, it definitely goes in much deeper detail than most documents I’ve seen before; he also does something that I strive for myself: described all the related topics: make, autoconf, automake and libtool, plus a number of related, but not directly-involved, topics.

For instance, he goes into two important topics that I have only written about in the blog up until now — Position Independent Code and library versioning — and then provides a whole chapter dedicated to tip and tricks, not only tied to Autotools. Some of the tricks were new also to me, and I’ve been floating in this topic for the best part of the past seven years (even before I joined as a Gentoo developer). Some further insights also show that he’s not tied to the Unix world itself, which is always a positive thing, as a lot of time we self-validate ourselves and can’t think outside that limited box.

Given these properties, I couldn’t find any reason not to list it on the further readings section of my own guide.

I could stop here with the review, and possibly make John and No Starch pretty happy, but I’d feel like I “sold” myself for the hope to actually keep a good contact with them as a publisher. But it wouldn’t be right for them either; I owe them my full opinion. Thus, I have now to move a few personal grudges I have with John’s approach, without reducing the sheer importance that this book has for all of us developers of Free Software that work with autotools daily: he stuck too much with the point of view of the Autotools’ upstream maintainers.

Don’t get me wrong, it’s obvious that diverting from the authors’ intention for any kind of software is bad, but I have fiercly criticized them before about their failure to get to agree to what should be used together. They insist that autoconf and libtool can be used standalone, without automake at all, they provide a number of support macros, but not all those you’d be expecting them to, and so on so forth. All these things actually make me pretty sad, and that’s why I’m trying my best on my text to actually write of a complete build system, using all three of them, plus pkg-config, which John mentions just in passing in the book, and that, as usual I’ll add, feels like a bastard child of the rest of the projects.

It actually pours more than just at that level; while he acknowledges the (must read) Recursive Make Considered Harmful by Peter Miller, he then states (I quote) “[T]he sheer simplicity of implementing and maintaining a recursive build system makes it, by far, the most widely used form of build system.” – Well, I cannot dispute the fact that it is the most widely used form; I can definitely argue a lot about the “simplicity”, especially considering that recursive build systems have atrocious support for parallelisation, and with modern machines growing more in number of cores (or execution threads) than they do in pure speed, that is an important detail to consider; especially for big projects.

Another thing that baffled me is that John is able to describe the Autoconf Archive without moving a comment about the policies regarding bundled and non-bundled macros in autoconf … add to that the way he dismisses most of the mistakes in the official documentation, or the idiosincratic behaviour of some macros, and that is what I call “siding with the authors” (by itself, of course, there is nothing wrong; he’s much more objective than I could ever be I guess). For those who want to take a laugh now, John’s book refers to the Autoconf Archive website; the Autoconf Archive website then links back to Autotools Mythbuster. Heh.

It can be opinable I guess, but for me, despide its subtitle defines it as a “Practical Guide”, I find it a good theoretical textbook; but I disagree that you should be using Autotools the way they are describe by John, or by the official documentation for what matters; like it or not, a lot of the technical decisions in those projects are taken after a political stance, and that shows on some recommendations that to me only hinder development and adoption of the tools. And in the current landscape where cmake is still preferred to build under Windows, and, luckily for all of us, scons is finally disappearing, dropping the politics, and simply provide a good pragmatic approach to practice is what I was hoping for.

Final words and sound bite/quotable opinion? John’s is an important book, as I already noted. It shows a stirring ecosystem of people working around Autotools; even though we disagree on views and in some technical details, his is the only current and complete text on the tools of the trade. If you’re a newcomer who want to know how it works behind the scenes in detail, you just have to read it. But if you’re interested in writing a good build system by modern standard, you cannot just stop here. John is showing you the door; but you’ve got to walk through it and proceed to the end of the corridor… deciding which further doors to peek into, and which ones to keep shut.

Comments 5
  1. I’d say that scons in the years improved a lot, sadly its users didn’t catch up yet. Waf is still better than cmake and scons for the task, yet less considered.Autotools obviously did improve but for most of the cases people didn’t catch up with them and you still have glaring misuse.

  2. I had thought at some point you might include/discuss Rake. You have at times discussed it on the blog. Ruby being ever so popular it’s inclusion could drive another book on build tools.Including also some discussion on testing the built application(s) is another option to broaden the subject a bit that might drive more interest from publishers.

  3. lu_zero: waf has a grave problem: It’s developer doesn’t want it in distributions. He has reasons for that, and they are mostly sound from a developer view, but if you don’t go with the maintainers, you can’t reach the devs easily.It isn’t in the tree, because he repeatedly told devs (and others, me included) not to put it in the tree, because it is „not to be installed“. For me that meant, I can’t easily create a build system on different devices (I really don’t want to manually install anything on my desktop, the university machine and the OLPC. And keep it up to date in multiple small projects which I want to share).

  4. I have purchased an own copy of this book after reading your review. I have even read more then 200 pages of it, and find it a good entrance to the gnu autotools thematics. This book is easy to read and follow for me, so I have a feeling that I understand the purpose of constructs and design decisions in many autotools based and gnome related projects. Computers are just one of my hobbies, and I wanted for years to gain a better knowledge about gnu building and open source software distributing process, but due to the fact that most of my current knowledge is based on hanging in the by freenode hosted channels, mailing list and forums (and a few books) I was kind of parallelized to be able to start reading gnu autools documentations, because of an endless number of bad rumors: that the autoconf and automake documentations are so outdated and confusing even for an experienced developer, not speaking of its reputation of being hard to configure… And the books about autotools on market were all not up to date – as at least ten years old. I was alone already scared by the number of autotools related filed were shipped with every project. So, Well, as a result, I never even gave it a try. facit: This book has helped me to overcome this barrier, so at the ending I was even surprised how easy it was to use autoconf, automake and libtool and many related helper tools.

  5. Diego: Thank you for the excellent objective review. Believe it or not, I agree with many of your nits about the book. For instance, I really wanted to add an entire section, if not a chapter, on the differences between recursive and non-recursive make systems. In fact, I worked hard to find a publisher who would publish this book. I’m grateful to the folks at No Starch Press who took on this project when others would not. Perhaps the autotools are controversial in the world of open source software, but they’re also some of the most pervasive build tools in the world. As such, they deserve a bit more attention than they’ve been given. Thanks again.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.