6.1 What is Portability?
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 section 24. 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.