In this article I finish the process we started in the last episode. Read on for the thrilling denouement.

After all the preparation described in the first part of this article the build process itself is rather anticlimactic. Building from sources with the GNU autotools is this easy :

    ./configure --help
    ./configure --with-optionYY=yes --with-optionZZ=no
    make
    sudo make install

The make command starts the build process. Its actions depend upon the directives found in a very important component called a makefile that typically includes a variety of commands to summon the required dependencies, compiles the individual object files (more about those files in a moment), links the objects into a single executable (a.k.a. the binary), and installs the completed program.

However, the source code must be configured before running the make utility. The following commands will display the configuration options for some of the more popular build managers :

    ./configure --help  (with the autotools system)

    ./waf configure --help 

    scons -h (local options)

    scons -H (global options)

Check for the available configuration options before proceeding to the make stage. The configuration stage will determine whether your environment includes the correct tools for constructing the software. It will also let you know about missing dependencies, version mismatches, special enhancements, and any other features or problems that will affect the build process.

A few words more regarding configuration options. Some may be enabled by default, while others must be manually added to the configuration stage. For example the following options declare the installation's target directory tree and adds support for the LAME MP3 encoder :

    ./configure --prefix=/usr/local --with-lame

When the build process has reached the linking stage the LAME library will be added to the library dependencies. When you run the installation procedure the program and its needed parts will be installed to the /usr/local directory hierarchy. Thus, the executable binary will be found at /usr/local/bin/progname, its headers will be in /usr/local/include/progname (or possibly just /usr/local/include), its examples and templates will be in /usr/local/share/progname, and so forth.

With Scons, once you've determined which options you want you simply add them to the scons build command in this manner :

    scons OptionA=1 OptionB=0

where 1 indicates that the option is to be used, 0 leaves it unused.

The waf system incorporates aspects of the autotools process :

    ./waf configure --help
    ./waf configure --prefix=/usr
    ./waf build 

Typically you can run waf with no options and it will return a list of available options and targets.

Assuming a best case, once the build process begins it will automatically run until it either completes the build or hits an unrecoverable error. Fortunately all build systems report critical errors in such a way that should assist in resolving the problems. The configuration stage can miss dependency details that won't appear until the compiler reaches the linking stage, the final step in the build process. You may find that a component is still missing or that a different version is needed, in which case you'll need to retrieve the required part or build it yourself. When you return to your original process it should restart the build from the point where the error occurred.

Installing your newly built software is easy, but it does require root (superuser) privileges. It also requires a specified installation directory. Typically you'll install a new program or utility in either the /usr or /usr/local hierarchy. The target directory can be indicated with the --prefix option for an autotools-based build or added to the build utility's configuration file (e.g. the Sconstruct file for scons). Such an option allows installation in any indicated directory, such as /opt or the user's $HOME directory. However, if you intend to run the program from anywhere within the system you must ensure that it is visible to the system by adding its path to the PATH statement, e.g. :

    export PATH=$PATH:/opt/mysoftware:/home/dave/bin

That command adds two new paths to the existing system path ($PATH). Now you can invoke programs in those paths from anywhere else in your system.

On some systems it is relatively safe to install new versions of software over the distribution's installed versions. However, care must be taken to indicate the correct installation path, else a double installation may occur. This situation is not going to blow up your system, but it will surely confuse it until you either remove the original files or re-install the new ones (after uninstalling them from their incorrect targets). It is also imperative that you know exactly what you're doing before upgrading or downgrading system components, especially components of the audio infrastructure. Applications may be version-dependent, so move rather than destroy the original components. You may yet need them to restore a borked system.

Look out for stale configuration files for applications, especially in your $HOME directory. It's best to remove them or copy them to a temporary directory, the application should replace them after a first run.

A final consideration for system software. Most installers will update the system library cache by invoking ldconfig at the end of the installation, though you may want to run it manually if you're unsure about the update. Also, make sure your installation target hierarchy (set with the --prefix configuration option) is included in /etc/ld.so.conf. It won't do much good to install something in /usr/local/bin if the /usr/local hierarchy is not in the system's library search path.

Okay, you built the program without troubles, you installed it successfully, you've run it, and it just isn't what you were looking for. You want the disk space back, so it's time to uninstall, an action that might be a simple one-line command or a nightmare of hunting for the installed parts and removing them by hand, one by one. Most build systems include mechanisms for uninstalling a program, such as the following commands for three popular systems :

  sudo make uninstall

  sudo scons -c install

  sudo ./waf uninstall

Your package manager can be used to remove components previously installed by your distribution. However, it is important to note whether the removal is normal or complete. A complete removal will uninstall all files associated with the package, including configuration and preference files. Complete removal is advised when you intend to replace system components such as ALSA or JACK, but the normal removal procedure should suffice for user-level applications.

I hope you've enjoyed this little technical tour, even if you're an old hand at rolling your own apps. As I said in the beginning of the tour, it's not rocket science, anyone can learn how to do it. Consider the instructions, proceed with deliberation, and trust your intelligence. I'm not a trained computer engineer, I have no background in computer science (or any other science), I don't even have a college degree, but I routinely compile, install, and configure the audio software I use here every day at Studio Dave. I get the best fit for my hardware, along with the satisfaction of knowing exactly what support has been built into my system. Truly, if a self-taught 59-year old musician can do it, you can too.