If you build open source software, you'll run into a lot of variants of the following list of commands:
cd (some directory)
./configure
make
sudo make install
Some common variants replace the ./configure with ./autogen.sh, or add some extra stuff on the end of that line or the make line. This article explains what's going on with this kind of command sequence.
Makefiles
If you look at most programs and other software components whose purpose is not trivial, they're made from more than one source file. There are several ways to tell a computer how to put all those source files together to create a component, and the most common is called a makefile. (There are also various kinds of project files that are used with development systems like Microsoft's Visual Studio, or Metrowerks' CodeWarrior.)
The Bad Old Days
The problem with makefiles is that they can need different contents to account for different computers and operating systems and compiler systems. For example, you might need one makefile for Linux on an x86 computer with version 3.4 of the gcc compiler, another for the same system using gcc 4.2, yet another for a Sun workstation running Solaris, and yet another for Mac OS X.
Up through the mid 1990s, the normal way to cope with this was to supply a different makefile for each combination of hardware, operating system, and compiler. That often meant a dozen or more makefiles. And if you had an unsupported combination, you had to write your own makefile.
Also, many software components rely on other software components, mostly known as libraries. But people work on libraries, so they change over time, and it's possible to get mismatches. For instance, if you write a program that works with PNG images, you'll probably want to use the "libpng" library. But there are different versions of libpng, and in the old days, if you wrote your program to work with one version, and somebody got your source code and tried to build it with a different version of libpng, the build might have failed, or the program might not have worked right. And makefiles have no reasonable way to check to see if you have the right version of a library.
The Good New Days
Several tools solve this whole problem - these are called the GNU Autotools, and pkg-config.
- The GNU Autotools create the configure file, which is a set of commands that builds a makefile for your particular computer, operating system, and compiler collection.
- Then the configure file typically uses pkg-config to make sure you have the right versions of any libraries you need, and complains if you don't.
- cd (some directory) makes that directory the current one.
- ./configure runs the configure script in that directory. That checks your operating system, compiler, CPU, and what libraries you have installed. If everything is okay, it creates a makefile in that same directory.
- make gets information from the makefile to build your software component
- sudo make install takes the component you built at the make step, and installs it where it needs to go on your computer to be useful.
Here are links about:
2 comments:
Welcome to blogville!
Seriously I've never been a fan of makefiles, they always seem like work the computer should be doing to maintain them. Since we worked on Trapeze I've always used an IDE or language that took care of all that. Now I prefer systems like PHP which trade compile time for runtime checks. But sadly I am also using XCode for the iPhone (argh).
I prefer projects too, such as those in the late lamented Metrowerks CodeWarrior. But a lot of open source projects use this system, and it is pretty portable.
A friend asked me to explain this system to him. But when I went looking online for things he could read, it all required a lot more background than he had. So I wrote this up.
Post a Comment