When I was asked to do a technical review on a book about the Autotools, I was rather skeptical. Several online tutorials and a few books already introduce readers to the use of GNU Autoconf, Automake, and Libtool. However, many of these texts are less than ideal in at least some ways: They were either written several years ago and are starting to show their age, contain at least some inaccuracies, or tend to be incomplete for typical beginner's tasks. On the other hand, the GNU manuals for these programs are fairly large and rather technical, and as such, they may present a significant entry barrier to learning your ways around the Autotools.
John Calcote began this book with an online tutorial that shared at least some of the problems facing other tutorials. Around that time, he became a regular contributor to discussions on the Autotools mailing lists, too. John kept asking more and more questions, and discussions with him uncovered some bugs in the Autotools sources and documentation, as well as some issues in his tutorial.
Since that time, John has reworked the text a lot. The review uncovered several more issues in both software and book text, a nice mutual benefit. As a result, this book has become a great introductory text that still aims to be accurate, up to date with current Autotools, and quite comprehensive in a way that is easily understood.
Always going by example, John explores the various software layers, portability issues and standards involved, and features needed for package build development. If you're new to the topic, the entry path may just have become a bit less steep for you.
PREFACE
I've often wondered during the last ten years how it could be that the only third-party book on the GNU Autotools that I've been able to discover is GNU AUTOCONF, AUTOMAKE, and LIBTOOL by Gary Vaughan, Ben Elliston, Tom Tromey, and Ian Lance Taylor, affectionately known by the community as The Goat Book (so dubbed for the front coveran old-fashioned photo of goats doing acrobatic stunts).[]
I've been told by publishers that there is simply no market for such a book. In fact, one editor told me that he himself had tried unsuccessfully to entice authors to write this book a few years ago. His authors wouldn't finish the project, and the publisher's market analysis indicated that there was very little interest in the book. Publishers believe that open source software developers tend to disdain written documentation. Perhaps they're right. Interestingly, books on IT utilities like Perl sell like Perl's going out of stylewhich is actually somewhat true these daysand yet people are still buying enough Perl books to keep their publishers happy. All of this explains why there are ten books on the shelf with animal pictures on the cover for Perl, but literally nothing for open source software developers.
I've worked in software development for 25 years, and I've used open source software for quite some time now. I've learned a lot about open source software maintenance and development, and most of what I've learned, unfortunately, has been by trial and error. Existing GNU documentation is more often reference material than solution-oriented instruction. Had there been other books on the topic, I would have snatched them all up immediately.
What we need is a cookbook-style approach with the recipes covering real problems found in real projects. First the basics are covered, sauces and reductions, followed by various cooking techniques. Finally, master recipes are presented for culinary wonders. As each recipe is mastered, the reader makes small intuitive leapsI call them minor epiphanies . Put enough of these under your belt and overall mastery of the Autotools is ultimately inevitable.
Let me give you an analogy. I'd been away from math classes for about three years when I took my first college calculus course. I struggled the entire semester with little progress. I understood the theory, but I had trouble with the homework. I just didn't have the background I needed. So the next semester, I took college algebra and trigonometry back to back as half-semester classes. At the end of that semester, I tried calculus again. This time I did very wellfinishing the class with a solid A grade. What was missing the first time? Just basic math skills. You'd think it wouldn't have made that much difference, but it really does.
The same concept applies to learning to properly use the Autotools. You need a solid understanding of the tools upon which the Autotools are built in order to become proficient with the Autotools themselves.
Why Use the Autotools?
In the early 1990s, I was working on the final stages of my bachelor's degree in computer science at Brigham Young University. I took an advanced computer graphics class where I was introduced to C++ and the object-oriented programming paradigm. For the next couple of years, I had a love-hate relationship with C++. I was a pretty good C coder by that time, and I thought I could easily pick up C++, as close in syntax as it was to C. How wrong I was! I fought with the C++ compiler more often than I'd care to recall.
The problem was that the most fundamental differences between C and C++ are not obvious to the casual observer, because they're buried deep within the C++ language specification rather than on the surface in the language syntax. The C++ compiler generates an amazing amount of code beneath the covers, providing functionality in a few lines of C++ code that require dozens of lines of C code.
Just as programmers then complained of their troubles with C++, so likewise programmers today complain about similar difficulties with the GNU Autotools. The differences between make
and Automake are very similar to the differences between C and C++. The most basic single-line Makefile.am generates a Makefile.in (an Autoconf template) containing 300400 lines of parameterized make
script, and it tends to increase with each revision of the tool as more features are added.
Thus, when you use the Autotools, you have to understand the under-lying infrastructure managed by these tools. You need to take the time to understand the open source software distribution, build, test, and installation philosophies embodied byin many cases even enforced bythese tools, or you'll find yourself fighting against the system. Finally, you need to learn to agree with these basic philosophies because you'll only become frustrated if you try to make the Autotools operate outside of the boundaries set by their designers.