| Autoconf, Automake, and Libtool | ||
|---|---|---|
| <<< Previous | Next >>> | |
Writing a portable configure.in is a tricky business. Since you can put arbitrary shell code into configure.in, your options seem overwhelming. There are many questions the first-time Autoconf user asks: What constructs are portable and what constructs aren't portable? How do I decide what to check for? What shouldn't I check for? How do I best use Autoconf's features? What shouldn't I put in configure.in? In what order should I run my checks? When should I look at the name of the system instead of checking for specific features?
Before we talk about the mechanics of deciding what to check for and how to check for it, let's ask ourselves a simple question: what is portability? Portability is a quality of the code that enables it to be built and run on a variety of platforms. In the Autoconf context, portability usually refers to the ability to run on Unix-like systems--sometimes including Windows.
When I first started using Autoconf, I had a hard time deciding what to check for in my configure.in. At the time, I was maintaining a proprietary program that ran only on SunOS 4. However, I was interested in porting it to Solaris, OSF/1, and possibly Irix.
The approach I took, while workable, was relatively time-consuming and painful: I wrote a minimal configure.in and then proceeded to simply try to build my program on Solaris. Each time I encountered a build problem, I updated configure.in and my source and started again. Once it built correctly, I started testing to see if there were runtime problems related to portability.
Since I didn't start with a relatively portable base, and since I was unaware of the tools available to help with adding Autoconf support to a package (see the chapter called Migrating an Existing Package to GNU Autotools), it was much more difficult than it had to be. If at all possible, it is better to write portable code to begin with.
There are a large number of Unix-like systems in the world, including many systems which, while still running, can only be considered obsolete. While it is probably possible to port some programs to all such systems, typically it isn't useful to even try. Porting to everything is a difficult process, especially given that it usually isn't possible to test on all platforms, and that new operating systems, with their own bugs and idiosyncracies are released every year.
We advocate a pragmatic approach to portability: we write our programs to target a fairly large, but also fairly modern, cross-section of Unix-like systems. As deficiencies are discovered in our portability framework, we update configure.in and our sources, and move on. In practice, this is an effective approach.
| <<< Previous | Home | Next >>> |
| Documentation and ChangeLogs | Brief introduction to portable sh |