Compiling source code on UNIX systems used to be a time consuming trial and error ordeal.

The reason that compiling software in the old days was so difficult is because there was no universal way to create a makefile for different machines and operating systems. A C compiler uses the makefile as a kind of blueprint that tells the compiler the steps needed to compile the source code into a usable binary file.

Binary files are the programs you're trying to run. They're also called executables.

In the old days when a developer was writing his/her code they were writing it to run on their machine. If you were running the same type of machine as the developer you were in good shape. If you were running a different type of machine you may or may not have been on your own to figure out how to get the program to compile.

Software written to run on one system under their structure would not necessarily compile on another vendor's UNIX variant under their structure.

If you wanted to run someone else's code from another architecture on yours it was up to you to figure out how to make it compile and work on your machine.

Writing software on UNIX has essentially gone through three different stages.

First was the Makefile stage. This was all you got. It was up to you to figure out which system libraries and which header files on your system were needed to make the program compile. Each system has its own header files.

Header files end in .h. These files define how C programs can access your system. They provide system definitions that programmers can use to write their code.

If your machine didn't have a "dependent" application or library you had to go out and redo the process all over again for those dependencies. Although this is still true today the biggest change is that there is now a system in place to help you create the Makefile whereas in the old days there was not.

The second era that software went through was the Imake stage. This stage was used mainly for X Windows applications. Since X Windows is pretty standard across all machines a system was developed to take advantage of this situation. An Imakefile was created. This was essentially a template that your system would use to help in the creation of a Makefile.

In addition to the applications Imakefile, your system had variables that it would supply to Imake that would then create the makefile for you. The biggest disadvantage to this system is that not all software was written with X Windows in mind and so it wasn't always applicable. There are other pluses and minuses to the Imake system that you can explore on your own if you desire. The GNU autoconf manual has a section towards the end that addresses the differences between Imake and autoconf.

The third stage of software development is the one we're in right now. This era of software development has tools that are designed to generate a makefile regardless of your hardware or operating environment. This stage uses the autoconf utilities to generate a makefile for your machine.

The autoconf utility uses a script called "configure" to create a makefile custom tailored for your hardware/operating system.

The autoconf utility tries to ease the process of having to write a different makefile for each vendor's hardware/operating system. The autoconf utility uses a variety of techniques and other programs to ascertain what UNIX system you're running on, runs some checks to see what your system has and doesn't have, checks for dependencies, and then creates a makefile for your system. This allows a developer to work on the source code and not worry so much about how to get it to compile on your machine. This frees up the developer to work on features and bug fixes, (also called features).

The web pages that follow will assist you in getting your machine ready to compile software, and then will attempt to walk you through the process for compiling software for each of the situations mentioned above. The first scenario I'll present you with is the autoconf method since it's in heavy use today. The first two compilation scenarios will be shown for completeness. Sometimes you have to resort to the old ways as well.

In addition there will be other topics covered such as how to create a package as well as a short dialogue on static versus dynamic libraries.

Next Section:  Preparing Your System To Compile Software (2 of 11)