Autotools 148
Muad writes "John Calcote is a senior software engineer in Novell's Linux business, who after slogging up the steep learning curve the Autotools triad poses to those packaging software according to the portable GNU conventions for the first time, very kindly decided to make the experience easier to newcomers by sharing his years of experience and carefully crafted bag of tricks. His book is a welcome update to a field that has not seen entries now for a full ten years, so long has been the time since GNU Autoconf, Automake, and Libtool by Gary V. Vaughn, Ben Ellison, Tom Tromey, and Ian Lance Taylor hit the shelves. Unfortunately, the publishing industry is driven by the need to turn a profit to fund its endeavors, and specialist items like this book are not obvious candidates for volume selling - which is a credit to No Starch Press' willingness to venture down this path." Keep reading for the rest of Federico's review.
The book opens with John's experiences in adopting the Autotools, and quickly offers what is in my view a very important word of caution that is often lacking in the few tutorials I have seen on the Net: the Autotools are not simply a set of tools but foremost the encoded embodiment of a set of practices and expectations in the way software should be packaged the GNU way. While it is acceptable for beginners not to know what these expectations are, the right frame of mind to approach the Autotools is to focus on learning what way the Autotools operate, what they are trying to accomplish, and why. Attempting to use the Autotools without understanding the bigger picture will lead to very high amounts of pain, as it is one of the toolsets most difficult to adapt for use separate from the policies they represent, so strongly are these conventions embedded in their fabric. With this understanding, it becomes possible to generate extensive configurations with a few lines of Autoconf or Automake - without this understanding, it very quickly becomes a battle to force a round peg into a square tool.| Autotools: A practitioner's guide to GNU Autoconf, Automake, and Libtool | |
| author | John Calcote |
| pages | 360 |
| publisher | No Starch Press |
| rating | 8/10 |
| reviewer | Federico Lucifredi |
| ISBN | 1593272065 |
| summary | Teaches how to master the Autotools build system to maximize your software |
John's style is more extensive and takes a longer path to the "technical meat" of the problem than the 10-year old alternative, but in this reader's opinion it flows significantly better as there is an underlying story, a thread that connects the bits of what is otherwise a pretty arid subject. For those masters of shell-fu, this book is a page-turner, while for mere mortals it is a good, approachable, path into a difficult skill.
The book is structured around the packaging of two different projects, the first being a simplified "Hello, World" project to provide a digestible introduction to the processes and technology of the Autotools, while the second representing the full-blown packaging of a complex, real-world project (the FLAIM high-performance database). This is a very good approach, breaking the theory into many practical examples of practice, and providing many ready-made bits that the rest of us can start our own configuration build files from. The result is a first half providing a gentler, streamlined introduction to the subject matter, before the full jump into the gory details of the most complex possibilities the toolset offers. While it must be noted that John attempts to keep away from those most fine details which "may be subject to change" between minor releases of the tooling, which is doubtlessly good for both our scripts' and the book's shelf life, it must be observed that he does not shy away from very dense (and otherwise utterly undocumented) material, such as the use of M4 macros in Autoconf, something a colleague of mine once pointed to me as "the one more reason I'd rather chew broken glass than deal with Autotools".
Assuming you have the requisite knowledge of Make, Shell scripting (particularly Bash), and GCC that are essential to a developer, packager, maintainer or buildmaster of a Linux, BSD or *NIX project, or that you are on your way to achieving those skills, this is a book that belongs in your shelf, right next to the RPM documentation. This is material for experts or experts in the making, but in my opinion you will find no better introduction to this complex subject. I had it on my wish list well before it was ever printed, and its presence on my desk caused several other developers in my office to order their copies pretty much on the spot upon finding out of its existence. Either as a learning tool for a skill you are trying to attain, or as a reference to turn to when faced with the complexities of this unique set of tools, this book is well worth its price tag.
I certainly hope this is not the last publication we see on the Autotools in this decade, but either way, it is a good start indeed - and my hope is that the publisher will refresh the title when an update is warranted, without waiting ten years!
Federico Lucifredi is the maintainer of man (1) and a Product Manager for the SUSE Linux Enterprise and openSUSE distributions.
You can purchase Autotools: A practitioner's guide to GNU Autoconf, Automake, and Libtool from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Let me get this straight: (Score:5, Informative)
Did I miss any novell/suses?
Re:Autotools do not need a book (Score:4, Informative)
I've run into the same problem with cmake. I don't really have that problem with python tools as python's virtual environment tools [python.org] seem to handle things nicely. Tools such as pip [python.org] natively handle virtual environments, automatically installing into it when one is active.
Also, there are lots of nice wrappers [python.org] to work with python's tools, for developers, such as gogo [bitbucket.org].
CMake (Score:5, Informative)
Re:Autotools do not need a book (Score:1, Informative)
Oh but I might still buy a copy. Just to wipe my @ss with. I can't begin to think of the hours I've wasted debugging build failures of this heap of cr@p.
Re:Shallow Learning Curve (Score:4, Informative)
Re:I suppose it's nice (Score:5, Informative)
It's true, pretty much. We developed configure scripts and ways to generate them in the days of 28.8kbps modems and they had to work on Unix System III and Xenix and HP-UX. We couldn't assume anything like Perl or Python was available. Linux distros were only just appearing, and there were no package management systems. Windows was still a 16-bit DOS shell. It was a different world. I'm amazed this stuff has endured as long as it has with so few changes. By the time Automake was written, several years after Autoconf, we at least felt we could assume the presence of Perl.
Want to know why it's called "Autoconf", which I think is a bit ugly of a name? I wanted to call it "Autoconfig", but when you add a version number and ".tgz" to that, you exceed the 14-character file name limit of some of the Unix variants it had to be downloaded and installed on!
Dave MacKenzie
Autoconf's main developer