Earnie Systems

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 masters.

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 over time.

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.