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.
Autotools do not need a book (Score:5, Insightful)
... they should be replaced by something else.
I suppose it's nice (Score:5, Insightful)
I suppose it's nice that someone writes a book like this, since a lot of existing projects use autotools (or more commonly, try to by means of copy/paste and cargo-cult based build scripting).
But autotools should really be phased out. It solves a lot of problems that aren't problems anymore, and makes a helluva lot of new ones in the process. There are a lot of up and coming build systems to challenge it, and then there's CMake which is an OK compromise between those and practicality.
Crappy Approach (Score:2, Insightful)
I would rather carve a Makfile into my arm (Score:3, Insightful)
RE: A not so Crappy Approach (Score:2, Insightful)
Those who don't understand Automake are doomed to repeat the mistakes of build systems that are not designed like Automake.
The one language that actually drives all of Automake is ML. Funny it is the one language you didn't list, but you listed a bunch of the high level macro files that get expanded with ML. If you don't know sh, then you shouldn't be programming on the command line (stick to an IDE that does the compilation for you). C isn't required for any component of Automake. If you write a makefile with automake, you made a big mistake, as Automake writes the makefiles for you.
There are other systems out there which are easier to use, but there's only a handful that does things in a manner that is highly reliable and portable on many platforms. Those that do strive for such goals end up operating like Automake, but often they do so without allowing such easy access to the internal guts of what is really going on.
Yes, I like cmake too, but bashing Automake just because you don't understand it is just the computer equivalent of name-calling.
Re: A not so Crappy Approach (Score:5, Insightful)
Hmmm... are you sure that you didn't mean the macro language M4? I thought that ML was the pure functional ancestor to languages like Haskell.
Anyway, I played around with M4 a little bit because I thought it looked handy for a few things. It has a deceptively simple specification that only takes a few pages, but it's one of the most extreme examples of "emergent behavior" I've encountered. Even simple tasks rapidly become mind boggling due to the deceptively tricky nature of recursive text substitutions and quoting. It's a real brain teaser of a language. It does seem like it would be a nifty tool if I spent enough time to really figure it out.
Re:Shallow Learning Curve (Score:5, Insightful)
Oh, for the love of jesus, not this again...
Yes, "learning curve" is a colloquialism that is not, literally, logically consistent. Move on already. Seriously.
Re:Autotools do not need a book (Score:3, Insightful)
If that were true you wouldn't have needed to say it
Re:I suppose it's nice (Score:4, Insightful)
> Care to point out what new problems autotools creates?
Builds that take half an hour just to "configure", checking for the existence of things like strcpy(), but anyway fail at compile or link time because a missing symbol in an upgraded dynamic library?
Re:CMake (Score:0, Insightful)
Why replace the GNU autotools with something even worse? CMake is the perfect build system for projects like pulseaudio and systemd, by which I mean software I wouldn't want to touch with a bargepole. CMake is a piece of fucking shit, or rather, -DCMAKE_IS_A_PIECE_OF_FUCKING_SHIT:BOOL:ON.
FOR ALL AUTOTOOLS "REPLACEMENTS" (Score:3, Insightful)
please note that all current 'replacements' are totally wrong and actually work only as puny build systems, not supporting any of the great portability benefits that autotools give. Scons, cmake, whatever else depend on their working installation on _build_ machine. This is wrong, only working shell+make+gcc should be needed to actually build software.
So...
Is there ANY good "replacement", preferably lightweight, with this great virtue? As far as I know, there's none.
Re:CMake (Score:1, Insightful)
I think it's a testament to how bloody awful Autotools is that people think CMake is an improvement!
Re:Autotools do not need a book (Score:2, Insightful)
"Now, it may well be that these are badly-written cmake scripts, and cmake is perfectly capable of doing it right"
The critics about the book make a point about "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".
It's not that cmake can or can't be properly used in order to provide a platform-independent prebuild environment but it lacks the grayback experience. As the old motto says, "those who don't understand UNIX are condemned to reinvent it, poorly". Unix-zen, once "the cool wave" is about 40 years old now. New generations feel they know better than the old farts (and many times, they are right) and that they can do it better and simpler... just because they are not (still) aware of the whole landscape and its corner-cases. So, yes, they might re-implement the old farts' tools better and simpler (after all, they have the advantage of building of top on the shoulders of giants, so to say) but, at the same time, they are condemned to fail on the same stepstones their olders managed to workaround just because they choose to ignore them, and then add their own package of failures.
"But it seems to me that cmake (and Python's easy-install, and every other new build scheme I've run across in the past few years) are all part of a new generation of tools which really want the build-time and run-time environments to be the same, because they're built around the "single-user isolated workstation" model."
Young is always proud and think to know better than anybody else. They just produce tools for what they know and they choose to ignore everything else. No wonder they fail on things that would seem trivial for older people that already had to fight with them years ago.
This is the generation of 'reinventing the wheel': they are doing better in some aspects and fail heavily on things that should be known by now.
Re:FOR ALL AUTOTOOLS "REPLACEMENTS" (Score:3, Insightful)
Re:Cross-platform, but not cross-compiling (Score:3, Insightful)
Now, configure something like CORBA targeting a PPC, but configuring on an X86, for compilation on an X86 using a cross compiler.
Oops - all your structure padding code for the CORBA martialling is broken, because the autoconf scripts all assume they can find out the padding of the structures by emitting a program, building it, running it (whoops! wrong arch!) and getting the output.
It's all well and good if the program is trivial enough that it does no serious probing of the system, or if the configure host is the same CPU type as the target, but break that, and unless the project's configure script is set up to correctly detect a cross compile, to provide a set of configuration parameters you can provide on the command line to set the variables that would normally be inferred by probing, AND has the wit to refuse to run without you providing those parameters because it detected you are cross compiling, and you will NOT get a running program by default, NOR will you be able to get one without major surgery on the configuration data by hand.