Fedora™ Unleashed, 2008 edition

> bugreport — To automatically collect and then mail a copy of the build or error logs

Large applications can require hundreds of source code files. Compiling and linking these applications can be a complex and error-prone task. The make utility helps you organize the process of building the executable form of a complex application from many source files.

Using the autoconf Utility to Configure Code

The make command is only one of several programming automation utilities included with Fedora. There are others, such as pmake (which causes a parallel make), imake (which is a dependency-driven makefile generator that is used for building X11 clients), automake, and one of the newer tools, autoconf, which builds shell scripts that can be used to configure program source code packages.

Building many software packages for Linux that are distributed in source form requires the use of GNU's autoconf utility. This program builds an executable shell script named configure that, when executed, automatically examines and tailors a client's build from source according to software resources, or dependencies (such as programming tools, libraries, and associated utilities) that are installed on the target host (your Linux system).

Many Linux commands and graphical clients for X downloaded in source code form include configure scripts. To configure the source package, build the software, and then install the new program, the root user might use the script like this (after uncompressing the source and navigating into the resulting build directory):

# ./configure ; make ; make install

The autoconf program uses a file named configure.in that contains a basic ruleset, or set of macros. The configure.in file is created with the autoscan command. Building a properly executing configure script also requires a template for the makefile, named Makefile.in. Although creating the dependency-checking configure script can be done manually, you can easily overcome any complex dependencies by using a graphical project development tool such as KDE's KDevelop or GNOME's Glade. (See the 'Graphical Development Tools' section, later in this chapter, for more information.)

Managing Software Projects with Subversion

Although make can be used to manage a software project, larger software projects require document management, source code controls, security, and revision tracking as the source code goes through a series of changes during its development. Subversion provides source code version control utilities for this kind of large software project management.

The Subversion system is used to track changes to multiple versions of files, and it can be used to backtrack or branch off versions of documents inside the scope of a project. It can also be used to prevent or resolve conflicting entries or changes made to source code files by multiple developers. Source code control with Subversion requires the use of at least the following five command options on the svn command line:

> checkout — Checks out revisions

> update — Updates your sources with changes made by other developers

> add — Adds new files to the repository

> delete — Eliminates files from the repository

> commit — Publishes changes to other repository developers

Note that some of these commands require you to use additional fields, such as the names of files. With the commit command, you should always try to pass the -m parameter (lets you provide a message describing the change) followed by some information about your changes. For example:

svn commit -m 'This fixes bug 204982.'

One of the most impressive features of Subversion is its ability to work offline — any local Subversion checkout automatically has a .svn directory hidden in there, which contains copies of all checked out files. Thanks to this, you can check your current files against the ones you checked out without having to contact the server — it all runs locally.

Debugging Tools

Debugging is both a science and an art. Sometimes, the simplest tool — the code listing — is the best debugging tool. At other times, however, you need to use other debugging tools. Three of these tools are splint, gprof, and gdb.

Using splint to Check Source Code

The splint command is similar to the traditional Unix lint command: It statically examines source code for possible problems, and it also has many additional features. Even if your C code meets the standards for C and compiles cleanly, it might still contain errors. splint performs many types of checks and can provide extensive error information. For example, this simple program might compile cleanly and even run:

$ gcc -o tux tux.c
$ ./tux

But the splint command might point out some serious problems with the source:

$ splint tux.c
Splint 3.1.1 --- 17 Feb 2004 tux.c: (in function main)
tux.c:2:19: Return value (type int) ignored: putchar(t[++j] -...
 Result returned by function call is not used. If this is intended, can cast
 result to (void) to eliminate message. (Use -retvalint to inhibit warning)
Finished checking --- 1 code warning

You can use the splint command's -strict option, like this, to get a more verbose report:

$ splint -strict tux.c

GCC also supports diagnostics through the use of extensive warnings (through the -Wall and -pedantic options):

$ gcc -Wall tux.c
tux.c:1: warning: return type defaults to `int'
tux.c: In function `main':
tux.c:2: warning: implicit declaration of function `putchar'

Using gprof to Track Function Time

You use the gprof (profile) command to study how a program is spending its time. If a program is compiled and linked with -p as a flag, a mon.out file is created when it executes, with data on how often each function is called and how much time is spent in each function. gprof parses and displays this data. An analysis of the output generated by gprof helps you determine where performance bottlenecks occur. Using an optimizing compiler can speed up a program, but taking the time to use gprof's analysis and revising bottleneck functions significantly improves program performance.

Doing Symbolic Debugging with gdb