5 Building Large Projects

 

  <--Last Chapter Table of Contents Next Chapter-->  

 

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.

NoteThe 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:
 

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:
 

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.

NoteThe 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

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

 
 

  <--Last Chapter Table of Contents Next Chapter-->