Using the C Programming Project Management Tools Provided with Ubuntu

Ubuntu is replete with tools that make your life as a C/C++ programmer easier. There are tools to create programs (editors), compile programs (gcc), create libraries (ar), control the source (Revision Control System [RCS] and the Concurrent Versions System [CVS]), automate builds (make), debug programs (gdb and ddd), and determine where inefficiencies lie (gprof).

The following sections introduce some of the programming and project management tools included with Ubuntu. The disc included with this book contain many of these tools, which you can use to help automate software development projects. If you have some previous UNIX experience, you will be familiar with most of these programs because they are traditional complements to a programmer's suite of software.

Building Programs with make

You use the make command to automatically build and install a C program, and for that use it is an easy tool. If you want to create your own automated builds, however, you need to learn the special syntax that make uses; the following sections walk you through a basic make setup.

Using Makefiles

The make command automatically builds and updates applications by using a makefile. A makefile is a text file that contains instructions about which options to pass on to the compiler preprocessor, the compiler, the assembler, and the linker. The makefile also specifies, among other things, which source code files need to be compiled (and the compiler command line) for a particular code module and which code modules are needed to build the programa mechanism called dependency checking.

The beauty of the make command is its flexibility. You can use make with a simple makefile, or you can write complex makefiles that contain numerous macros, rules, or commands that work in a single directory or traverse your file system recursively to build programs, update your system, and even function as document management systems. The make command works with nearly any program, including text processing systems such as TeX.

You could use make to compile, build, and install a software package using a simple command like this:

# make install 

You can use the default makefile (usually called Makefile, with a capital M), or you can use make's -f option to specify any makefile, such as MyMakeFile, like this:

# make -f MyMakeFile 

Other options might be available, depending on the contents of your makefile.

Using Macros and Makefile Targets

Using make with macros can make a program portable. Macros allow users of other operating systems to easily configure a program build by specifying local values, such as the names and locations, or pathnames, of any required software tools. In the following example, macros define the name of the compiler (CC), the installer program (INS), where the program should be installed (INSDIR), where the linker should look for required libraries (LIBDIR), the names of required libraries (LIBS), a source code file (SRC), the intermediate object code file (OBS), and the name of the final program (PROG):

# a sample makefile for a skeleton program CC= gcc INS= install INSDIR = /usr/local/bin LIBDIR= -L/usr/X11R6/lib LIBS= -lXm -lSM -lICE -lXt -lX11 SRC= skel.c OBJS= skel.o PROG= skel skel:  ${OBJS}         ${CC} -o ${PROG} ${SRC} ${LIBDIR} ${LIBS} install: ${PROG}         ${INS} -g root -o root ${PROG} ${INSDIR} 

Note

The indented lines in the previous example are indented with tabs, not spaces. This is important to remember! It is difficult for a person to see the difference, but make can tell. If make reports confusing errors when you first start building programs under Linux, check your project's makefile for the use of tabs and other proper formatting.

Using the makefile from the preceding example, you can build a program like this:

# make 

To build a specified component of a makefile, you can use a target definition on the command line. To build just the program, you use make with the skel target, like this:

# make skel 

If you make any changes to any element of a target object, such as a source code file, make rebuilds the target automatically. This feature is part of the convenience of using make to manage a development project. To build and install a program in one step, you can specify the target of install like this:

# make install 

Larger software projects might have a number of traditional targets in the makefile, such as the following:

• test To run specific tests on the final software

• man To process an include a troff document with the man macros

• clean To delete any remaining object files

• archive To clean up, archive, and compress the entire source code tree

• 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 Ubuntu. 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 ; sudo 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 section "Graphical Development Tools," later in this chapter, for more information.)

Managing Software Projects with RCS and CVS

Although you can use make 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. CVS provides source code version control utilities for this kind of large software project management. You can find this utility in APT packages on your Ubuntu DVD.

The CVS 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 CVS requires the use of at least the following six command options on the cvs command line:

• checkout Checks out revisions

• update Updates your sources with changes made by other developers

• add Adds new files in cvs records

• import Adds new sources to the repository

• remove 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.

Tracking information is usually contained in separate control files; each document within a project might contain information that is automatically updated with each change to a project. A process called keyword substitution is used to perform these automatic updates. CVS uses keywords included inside C comment strings (/* */) near the top of a document. The following are some of the available keywords:

• $Author$ The username of the person who performed the last check-in

• $Date$ The date and time of the last check-in

• $Id$ Same as $Header$, but without a full pathname

• $Name$ A symbolic name (see the co man page)

• $Revision$ The assigned revision number (such as 1.1)

• $State$ The state of the document, such as Exp for experimental, Rel for released, or Stab for stable

Getting started with CVS requires that you initialize a repository by first setting the $CVSROOT environment variable with the full pathname of the repository and then using the init command option with the cvs command, like this:

# cvs init 

You can find documentation for CVS in various man pages, under the /usr/share/doc directory, and in GNU information documents.

Debugging Tools

Debugging is both a science and an art. Sometimes, the simplest toolthe code listingis 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 

The GNU C compiler 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' 

Note

If you would like to explore various C syntax-checking programs, navigate to http://www.ibiblio.org/pub/Linux/devel/lang/c. The splint program is derived from lclint, which you can find in the lclint-2.2a-src.tar.gz file at the website.

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

The gdb tool is a symbolic debugger. When a program is compiled with the -g flag, the symbol tables are retained, and a symbolic debugger can be used to track program bugs. The basic technique is to invoke gdb after a core dump (a file containing a snapshot of the memory used by a program that has crashed) and get a stack trace. The stack trace indicates the source line where the core dump occurred and the functions that were called to reach that line. Often, this is enough to identify a problem. It is not the limit of gdb, though.

gdb also provides an environment for debugging programs interactively. Invoking gdb with a program enables you to set breakpoints, examine the values of variables, and monitor variables. If you suspect a problem near a line of code, you can set a breakpoint at that line and run gdb. When the line is reached, execution is interrupted. You can check variable values, examine the stack trace, and observe the program's environment. You can single-step through the program to check values. You can resume execution at any point. By using breakpoints, you can discover many bugs in code.

A graphical X Window interface to gdb is called the Data Display Debugger, or ddd.