Tools and Development Environment (make & cvs)

The following examples describe how to use the make and cvs tools. This very short guide is not intended as a replacement for the corresponding manuals.

Make

Make is a utility for building and maintaining programs. In a more general definition, it can be described as a dependency management tool (in the sense that is controls how targets are updated when dependencies change).

Make is especially useful for managing large programs, in which multiple, often not obvious, dependencies occur.

In general, make reads its rules from a "makefile", but it may be built with implicit rules for frequently used tasks. A makefile is a sequence of definitions (of variables, rules, and directives). The first explicit rule is the default (i.e., the one whose target is to be built if no target is specified).

Below, the most usual features are covered (other features, such as conditionals and cycles are not, since they are not of special interest in most cases).

Variables

Make variables may be initialized with literals or with the result of commands. The following definitions have the same result (assuming that the directory contains source files named file1.src through fileN.src.

 SRCFILES = file1.src file2.src ... fileN.src   <----- literal initialization
 SRCFILES = $(wildcard *.src)                   <----- wildcard initialization
 SRCFILES = $(shell ls *.src)                   <----- use output of shell command

Access to a variable is done by using the $ sign followed by a single character (if the variable name has more than one character, then it must appear in parenthesis). In addition to user-defined variables, make also defines automatic (pseudo-)variables (the list is not exhaustive).

 $(SRCFILES)    <----- access to variable SRCFILES
 $<             <----- first dependency (pseudo-variable)
 $^             <----- all dependencies (pseudo-variable)
 $*             <----- pattern match (pseudo-variable)
 $@             <----- current target name (pseudo-variable)

Some variables are pre-defined by most make distributions. These are normal variables and may be redefined by the user. The following list shows some of the most common (the list is not exhaustive).

• CXX, CXXFLAGS - the C++ compiler and corresponding compilation flags
• CC, CFLAGS - the C compiler and corresponding compilation flags

A variable may be defined based on another: for instance, considering the above SRCFILES variable, we could define a new list by editing the previous one, replacing the .src with another (in our example, with .der, for "derived").

 DERFILES = $(SRCFILES:%.src=%.der)

Rules

The general syntax of a rule is as follows (target is supposed to be "built" by the commands 1 though N):

 target: dependency1 dependency2 ... dependencyN
         command1
         command2
         ...
         commandN

There are two types of rules: implicit, which make uses for derived building targets from derived (calculated) dependencies; and explicit, in which both targets and dependencies are specified.

The following is an example of an implicit rule for obtaining a compiled (.o) file from a C++ (.cpp) source, by simple compilation. Variable CXXFLAGS is used to specify compilation flags and CXX is the compiler's name (g++ by default).

 CXXFLAGS=-ggdb -O3

 %.o: %.cpp
         $(CXX) $(CXXFLAGS) -c $*.c -o $*.o

In this rule, % represents a pattern (the same pattern appears in commands section represented by the $* pseudo-variable).

The same rule could be written thus (here $< represents the first dependency, and $@ the target to be built by the rule):

 %.o: %.cpp
         $(CXX) $(CXXFLAGS) -c $< -o $@

 a.o: a.cpp x.h  y.h
 b.o: b.cpp x.h
         $(CXX) -DSPECIAL $(CXXFLAGS) -c $< -o $@

Additional dependencies cannot be specified in the above rule, but, since make accumulates the dependencies for a given target, additional dependencies may be specified by compatible rules. These additional rules do not need a section with commands (the commands in the implicit rule will be used). Nevertheless, if there are commands in both an implicit and an explicit rule, the explicit's are used. In the first example, a.cpp would depend on x.h and y.h, while b.cpp would depend on just x.h and use a special compilation command.

Comparable explicit rules would be:

 a.o: a.cpp x.h y.h
         $(CXX) $(CXXFLAGS) -c $< -o $@

 b.o: b.cpp x.h
         $(CXX) -DSPECIAL $(CXXFLAGS) -c $< -o $@

Note that in the case of implicit rules (the most frequent), file dependencies can be computed automatically, for instance with GCC. The following examples assume that all files are in the current directory. If they are not, then the second set of examples could be used (CXXFILES is a variable containing the list of C++ source files:

 g++ -M  *.cpp              <--- computes all dependencies (system and local)
 g++ -MM *.cpp              <--- computes all dependencies (only local dependencies)

 g++ -M  $(CXXFILES)        <--- computes all dependencies (system and local)
 g++ -MM $(CXXFILES)        <--- computes all dependencies (only local dependencies)

Of course, it is possible to build a rule for updating the dependencies and many projects do it:

 depend:
         $(CXX) -MM $(CXXFLAGS) $(CXXFILES) > .makedeps

 -include .makedeps

The minus (-) sign before the include instruction indicates that processing should not stop if .makedeps does not exist (normally, and if nothing is told otherwise, make stops when an error occurs).

Examples

• See the makefiles in the CDK3, RTS, and Compact distributions: those makefiles perform various tasks and use many of the described features.
• See also the toy examples below.

CVS

This is a very short introduction to CVS, the Concurrent Versions System. Further information should be obtained from the official sources and manuals.

Structure

File:CVSInteractions.png CVS defines a source repository that will be the hub for all the entities involved in a project. Each entity will request a module (in CVS parlance, a directory belonging to a tree controlled by the repository) to work on locally. Then, each local copy may be the object of several editing and management operations for keeping it in sync with the repository. Since changes are concurrent, compatibility problems may arise during the life of a local copy, until it again becomes synchronized with the central repository (see image).

The first contact with CVS may depend on the specific project and participants: the repository and/or the project may not yet exist (and have to be created), or they may both already exist (in which case, only check-out, update, and commit operations are performed).

The repository's location may be specified directly as an option to the "cvs" command: <bash>

 cvs -d /root/of/the/cvs/repository some-cvs-subcommand

</bash> Or it may be read from the CVSROOT environment variable (defined, for instance, in the shell's configuration file): <bash>

 export CVSROOT=/root/of/the/cvs/repository
 cvs some-cvs-subcommand

</bash> Various modes of access are possible: local (i.e., direct access to the CVS repository's file system exists) or remote (otherwise). Remote access may be done through CVS's own protocol (pserver), but this is insecure. Another remote access method is the one specified by the CVS_RSH command (which defines the method for extended access methods). A common definition for this variable (in fact, the default in some systems) is "ssh": <bash>

 export CVS_RSH=ssh

</bash> The CVSROOT variable now can be written as: <bash>

 export CVSROOT=:ext:username@compiladores.rnl.ist.utl.pt:/root/of/the/remote/cvs/repository

</bash>

Examples

• See below.

Examples

• Make/CVS example 1 - solution for "aula prática 03"
• Make/CVS example 2 - solution for "aula prática 03"