Big Online Book of Linux Ada Programming - 5 Building Large Projects

5 Building Large Projects

5.1 Make: The Traditional Project Builder

IDE: TIA supports make. To use make, select it in the project parameters window.

Gnatmake is the best tool for building small projects. However, if you have a lot of C functions, you may want to use Linux's traditional project building command, make.

The make command interprets a series of rules saved in a file called "Makefile". These rules describe which files are dependent on which other files. Each rule is followed by the command needed to update the files, such as the command to compile them.

For example, if you had a Ada program called dbase and it relied on the source files common.adb, scanner.adb and parser.adb, a Makefile might include the rule:

dbase: common.o scanner.o parser.o

gnatlink —o dbase

This rule says that the dbase executable file depends on the object files for the 3 Ada source files, and to update dbase make has to link the object files with the gnatlink command.

If you are writing an Ada program with C source files, the basic strategy for using make with gnat is to make rules than ensure the C files are compiled properly, and then to finish the project using Gnatmake.

Makefiles can have comments and variables and rules that refer to parameters to the make command as opposed to files. The many options can't be covered here.

5.1.1 A Simple Ada Makefile

The following Makefile will compile an Ada program called main.adb, plus any packages used by main. This should work for most small projects. Edit the OBJS variable to include the object files for every package used by your program.

To use this make file, type "make" to build your Ada project, or "make clean" to remove any intermediate files produced by the compiler.

The ALT version of Gnat uses uses the name gnatgcc, not gcc, for the GCC compiler.

# Sample Ada makefile

#

# Assumes main program is named main.adb

#

# by Ken O. Burtch

OBJS = main.o somepackage.o

# How to compile Ada files

.adb.o:

gcc -c $<

.SUFFIXES: .adb .o

# How to link the main program

main: $(OBJS)

gnatbind -xf main.ali; gnatlink main.ali

clean:

rm *.o *.ali core

5.2 Cook: A Parallel Make

IDE: TIA supports cook. To use cook, select it in the project parameters window.

cook is a program for building projects. Unlike make, cook has additional features such as the ability to define true variables and functions, and the ability to build a project using multiple machines in parallel. This can be a useful tool for large Ada projects.

cook also comes with a tool to convert Makefiles to cook Howto.cook files.

If you need to install cook, there are four basic steps are:

configure # run GNU configure
make # build cook
make sure # verify cook by running tests
make install # install cook on your computer

When you type "cook", cook looks for a file called Howto.cook. This file, called a "cookbook", contains rules, or "recipes", for building a project.

Each rule has three parts:

targets - the files built with this rule (e.g. the object file names)
ingredients - the files need to do the building (e.g. source code fields)
body - the commands to do the work. these can include other rules.

Here is an example Howto.cook file with one rule:

main: main.adb

{

gnatmake main.adb;

}

The target is "main". To create main, cook must examine main.adb. If main.adb is newer than main, cook creates a new main by running the Gnatmake command.

Cook comes with some predefined rules for compiling certain kinds of files. These predefined cookbooks can be attached to your Howto.cook file by using "#include". For example,

#include "c"

includes basic rules describing the relationships of C files to each other.

5.2.1 Cooking in Parallel

Cook can use the rsh command to build several parts of a program at once, either on a computer with multiple CPU's or over a network. If rsh hasn't been configured, you'll need to do this before you can run cook. For example, all the computers should have the source directory mounted via NFS under the same mount directory. Also, the clocks on all the computers should be set identically or cook may be confused by the age of the files.

To cook in parallel, run cook with the -par switch. This option indicates the number of computers cook can use, the default being 4. You can indicate fewer computers. For example, -par=2 will run cook using 2 computers.

To indicate which machines to use, assign the hosts to the parallel_hosts variable.

parallel_hosts = first_computer second_computer third_computer

Simple Howto.cook files will compile in parallel without any modification.

5.2.2 A Simple Ada Cookbook

The following Howto.cook file will compile an Ada program called main.adb, plus any packages used by main. This should work for most small projects. Edit the OBJS variable to include all the object files from the packages you are using.

To use this make file, type "cook" to build your Ada project, or "cook clean" to remove any intermediate files produced by the compiler.

The ALT version of Gnat uses uses the name gnatgcc, not gcc, for the GCC compiler.

/* ---------------------------------------- */

/* This is a simple Ada Howto.cook cookbook */

/* */

/* it assumes the main program is named */

/* main.adb */

/* */

/* by Ken O. Burtch */

/* ---------------------------------------- */

OBJS = main.o somepackage.o;

/* How to compile individual Ada files */

%.o: %.adb {

gcc -c %.adb;

}

/* How to compile individual C files */

/* ( Just in case we want to mix C and Ada ) */

%.o: %.c {

gcc -c %.c;

}

/* How to bind and link the main program */

main: [OBJS] {

gnatbind -xf main.ali;

gnatlink main.ali;

}

/* How to clean up intermediate files */

clean: {

rm *.o *.ali core;

}

There are many other features in cook not covered here. More information about cook can be found in the Cook User Manual and the Cook Reference Manual.

5.3 Automake and Autoconf: UNIX Portability

If you want to create projects that run on a variety of UNIX platforms, not just Linux, you'll want to look at GNU autoconf and automake. The GNU tools use these programs extensively.

Included with Linux, autoconf creates a shell script called "configure". Customized for your project, when this script is executed, it scans the features of the particular UNIX that it is running on and tailors all Makefiles accordingly. It optionally produces a C file called "config.h" which contains information about the features it found.

automake, the other half of autoconf, creates a Makefile.in using templates called "Makefile.am". Once automake is finished, all you have to do is run "configure" to make your final makefile and type "make" to build the project on any version of UNIX.

It is possible to use autoconf and automake on Ada Makefiles, but this topic is beyond the scope of this book. More information on automake and autoconf can be found using "info autoconf" and "info automake".

The following is an example of what happens when you run an autoconf configure script, as run for the FreeAmp program.

checking host system type... i686-pc-linux

checking for a BSD compatible install... (cached) /usr/bin/install -c

checking whether build environment is sane... yes

checking whether make sets ${MAKE}... (cached) yes

checking for working aclocal... found

checking for working autoconf... found

checking for working automake... found

checking for working autoheader... found

checking for working makeinfo... found

checking whether make sets ${MAKE}... yes

checking for gcc... gcc

checking whether the C compiler (gcc) works... yes

checking whether the C compiler (gcc) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking for c++... c++

checking whether the C++ compiler (c++) works... yes

checking whether the C++ compiler (c++) is a cross-compiler... no

checking whether we are using GNU C++... yes

checking whether c++ accepts -g... yes

checking for POSIXized ISC... no

checking for ranlib... ranlib

...

checking for libc5... no

checking for dlopen in -ldl... yes

checking for MIT PThreads... no

checking for Base LinuxThreads... yes

checking for LinuxThreads w/ErrorCheck Mutex... yes

checking for sys/asoundlib.h... no

creating ./config.status

creating Makefile

...

creating config/config.h

5.4 PRCS: Project-wide Source Control

PRCS, the Project Revision Control System, is a source control system designed for large projects. It is easier to use and requires less administration than CVS, especially when a large number of files is involved. For example, PRCS (almost) always performs all actions across the entire project while CVS commands act only on your current position: if you are in a subdirectory, CVS only updates the subdirectory while PRCS will back up to the root directory for the project before performing any work. PRCS also handles file permissions while CVS does not.

Like CVS, PRCS uses a directory called a repository to store project files. The repository is directory is specified in a PRCS_REPOSITIORY environment variable.

PRCS uses project files, .prj, to manage sets of files at once. Use the project file to control PRCS's behaviour, such as listing file names or extensions that you don't want to add to a project.

Basic command include

prcs checkout project - check out a project
prcs populate - search for new files and add them to the project
prcs checkin - commit the changes to the repository to share them with the team
prcs depopulate project files - remove files added to a project
prcs admin - perform administration functions such as setting file permissions

You can find out more about, and get the latest version here: http://www.xcf.berkeley.edu/~jmacd/prcs.html