We all have the potential to create great and mighty
systems that would be useful to many masters of computer environments and
masters of computer business algorithims. For the most part Information
Technology or what ever it is you call processing data with dumb electrical
machines, is all the same with differences being related to how the methods
of controlling the dumb electrical machine were crafted by their associated
The most commonly used ABI/API sets for kernel OS
systems are for the Windows platform as described by it's creators Microsoft
Corporation and UNIX as described by it's creators and enhancers. Even
between differing versions of platforms the ABI/API may be different and
must be dealt with. However, the differences between the each platform
ABI/API are tremendous. For example the way that you do interprocess
control and communication are vastly different between UNIX and Windows.
Traditional open source solutions target the UNIX
platform. Even so, open source solutions must deal with complexities
of portability if they expect to be used by more than one vendor and more
the one permutation of UNIX platform. The issue of portability becomes
even a bigger issue as we look at the differences between the ABI/API of
various platforms as crafted by their masters and even more with permutations
There are tools of the open source trade that have
evolved over time that try to help with this portability issue. These tools
are maintained separately but are often called collectively as autotools.
The first of these tools is known as autoconf and is used to help determine
what exists in the build environment and what you have in the form of objects
for the target and host objects and setting constant values in a configuration
header file that is typically named config.h. You then use the constants
in your source to include header files if they exist or to supply you own
version of a function if it doesn't exist. Autoconf itself isn't for
the end user, it is a maintainer tool; however, autoconf produces a configure
Bourne shell compliant script that is executed in a POSIX enviroment. Now,
there's a situation for you, not all Bourne shell's act the same way. You
can imagine the headaches and autoconf maintainer burnout that must happen
when autoconf itself must be as portable as possible. Autoconf tries
to be compatible with older legacy platforms and permutations of various
platforms as it can be and still provide functionality for the more widely
used systems of today.
Another of these autotools is know as automake.
It tries to aid in the creation of the Makefile.in file which is a
template file for autoconf that is used by the configure script to help create
the Makefile that will be used to build the application. It's worries
for poritbility deal mainly with the permutations of the make utility that
uses the Makefile.
And yet another is libtool. Libtool deals
with issues of libraries, both static and shared. It also interfaces
with autoconf and depends on it for putting it's parts into the configure
script and eventual Makefile.
|®Windows is a registered trademark of Microsoft Corporation.