Once the developer has checked out the sources and selected a base release, it is time to start using the build environment tools. The picture here is quite a bit more complicated than on the source code management side. However, the fundamentals are relatively easy, and one just needs to learn the cycle in which to use the tools. These aspects are illustrated in Figure 4-2, ``Build Tools''.
Non-SRT tools involved in this process are GNU make and GNU autoconf, both of which get input from both the developers and the release tools. GNU make is the utility that incrementally builds executables and libraries from the source code. To do its job, it needs to have a makefile that describes what is to be done. The description comes in the form of rules that define targets that can be generated from a list of dependencies by applying a set of commands. Make examines the rules and decides what needs to be done to get the executables and libraries up to date. Certain rules are applied to produce object files from source files, while other rules are applied to create libraries and executables from the object files.
Large parts of the makefiles tend to be the same from one package to another. This is because the rules to build an object file from a source file tend to stay the same. Nevertheless, they have the habit of getting long and complicated as one deals with the quirks of different compilers and operating systems. SRT factors all those commonalities and platform depenendencies out to a ``standard'' makefile body. The developer writes only a small abstract makefile that describes what is to be built and what sources to include each target, and the rest of the logic is included from SRT.
Packages also need to adapt themselves to the developer's environment. A good way to do this is to use a shell script that looks around a little bit and determines which settings to change to make the package compile in that environment. GNU autoconf was conceived for this purpose: one gives it a simple template that describes what checks need to be made, and autoconf produces a shell script that will perform those checks.
An example of automatic configuration is that a package needs to find the other packages it uses. It can adjust to the situation where the developer has not checked out the other packages and look for them in the base release. Another example--the actual reason why autoconf exists--is a package that uses the operating system's interfaces a lot: it will need to find out exactly what the operating system is capable of doing, and adjust its behaviour accordingly. The reason for doing this is that various operating systems and even different versions of the same operating system tend to have horribly variable interfaces for doing one and the same thing. Hence, it makes sense to discover those features dynamically, and as long as the source code can accommodate the variation, the package will compile on a large number of target platforms--even on ones it has not been previous ported to.
In summary, the developer includes a configuration template as a part of the sources and uses autoconf to produce the real configuration script. SRT also adds functionality into the script, to cater for the automatic adjustment to different package locations and to determine what the package's dependencies are. Both the configuration script and the template are then included with the source. When someone wants to compile the package, he or she runs the configure script. It does its work of determining settings and produces a makefile and possibly other files such as headers. The generated makefile is again based on the template written by the package author: the configure script just does some simple text editing on it. The generated makefile and other data produced by the configuration script are then fed into make. Together with the SRT's makefile logic make will decide what to do.