[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]

COMP2100/2500
Lecture 24: Make and RCS

Summary

An introduction to two of the standard tools for managing larger programs: the build tool make and the version control tool RCS.

Aims

• Explain what these tools are for and why you need them.

• Introduce the concepts needed to understand them.

• Show how to use them in some fairly simple situations.

• Give you enough background to get started on Lab 5.

---

Build Tools

Why do we need build tools?

• Large systems may have hundreds of source files.

• Recompiling all files can take hours or days!

• Manually compiling individual files is slow and error prone.

What can a build tool do for you?

• Determine which files need to be compiled.

• Issue the commands to compile them.

---

Do I Really Need a Build Tool?

Can't smart compilers like the one for Java do that for me?

Yes, but:

• This is not possible in some languages, like C and C++, where a compiler can't tell which files depend on which.

• Many systems are built using multiple languages. No single compiler can build such systems.

• Build tools can do more than just automate compilation:

  • They can automate testing of modules.

  • They can automate documentation extraction.

  • They can automate all sorts of more complex tasks. For example, the COMP2100 web pages are maintained with one.

---

File Dependency Example

strcnt.h

Prototype for a string length function.

strcnt.c

Source code for a string length function.

harness.c

Test harness for string length function.

tests.txt

Test cases for string length function.

---

How Do I Use a Build Tool?

You must tell a build tool the following things about your system:

• Which files depend on which.

  E.g. harness depends on strcnt.o and harness.o.

(What does depend on mean? It means that if either of those `.o' files changes, then the executable will have to be rebuilt.)

• How to build files from each other.

  E.g. gcc -Wall -o harness strcnt.o harness.o links strcnt.o and harness.o to produce harness.

Operating systems tag files with the time of their last update. Build tools compare the ages of files and rebuild new versions appropriately.

For example, if harness is missing or older than strcnt.o or harness.o, a build tool would run `gcc -Wall -o harness strcnt.o harness.o' to update it.

---

Make: A UNIX Build Tool

The UNIX make command requires an input file, called `makefile' (or `Makefile'), to describe the dependencies between files and how to update them.

A makefile consists of multiple entries of the following format:

file-name: other files it depends on
        commands to build it

Note: Commands must be indented by a Tab character, not 8 spaces.

The file named before the colon is called a target.

To update the file f with respect to the files on which it depends, type `make f' into the shell.

Just saying `make' updates the first target named in makefile.

---

An Example Makefile

tests.log: harness tests.txt
        ./harness < tests.txt > tests.log

harness: harness.o strcnt.o
        gcc -Wall -o harness harness.o strcnt.o

harness.o: harness.c strcnt.h
        gcc -Wall -c harness.c

strcnt.o: strcnt.c strcnt.h
        gcc -Wall -c strcnt.c

---

Using the example Makefile

[comp2100@karajan]$ rm -f tests.log harness *.o
[comp2100@karajan]$ make
gcc -Wall -c harness.c
gcc -Wall -c strcnt.c
gcc -Wall -o harness harness.o strcnt.o
./harness < tests.txt > tests.log
[comp2100@karajan]$ emacs strcnt.c
[comp2100@karajan]$ make
gcc -Wall -c strcnt.c
gcc -Wall -o harness harness.o strcnt.o
./harness < tests.txt > tests.log

---

Phony Targets

You can declare targets that give names to actions that do not correspond to files. These are called phony targets.

Example: We can use a phony target to remove all the automatically generated files.

clean:
        rm -f harness harness.o strcnt.o tests.log

If you run make clean, make should discover that there is no file called `clean', so it runs the command. (After which, there is still no file called `clean'.)

---

More Phony Targets

We can use a phony target to build a list of files.

all: file1 file2 ...

If you run make all, make should discover that there is no file called `all'. Before it realises that there is no command to build all, it will first update each of the dependencies.

Note: In most makefiles, the first target is a phony target called all that depends on a list of files to be updated when Make is run without arguments.

---

Version Control

Maintenance will produce many versions of a module.

revision:

A new version of a module intended to replace the old one. For example, when you fix a fault in the module.

variation:

A new version of a module that will co-exist with the old one. For example, when you port a system to a new operating system.

You need to keep all the versions of all the modules because:

• A new revision may introduce a worse error than it fixes.

• Different customers may have different versions of the system.

• The client may decide they liked the old version better.

Keeping track of all these versions requires a tool.

---

What Can a Version Control Tool Do?

• Give easy storage and access to all the versions of a module.

• Remember which versions of which modules go together.

• Store descriptions of each change made to a module.

• Be able to identify the version of any module, either source or object code.

• Cooperate with a build tool to build particular configurations of a system.

• Ensure two programmers don't modify the same version at the same time.

---

RCS: A UNIX Version Control Tool

Versions of file f are stored in f,v. Versions files may be in a subdirectory called RCS.

Example:

---

Some RCS Commands

co strcnt.h

Check-out a read-only copy of the latest version of strcnt.h.

co -r1.4 strcnt.c

Check-out a read-only copy of version 1.4 of strcnt.c.

co -l harness.c

Check-out a writable copy of the latest version of harness.c. The file is locked so that only the user can update it.

ci harness.c

Check-in a new latest version of harness.c, only available to the user who has it locked. The file harness.c is then unlocked. The user is prompted to describe the changes made to the file.

rlog tests.txt

Describe the history of changes made to this file.

co -d"25 December" strcnt.c

Check-out the last version of strcnt.c from before (or maybe on) Christmas Day.

---

Efficiency Issues with RCS

Storing every version of each file for a big, long lived, project would use too much space.

To avoid this problem RCS uses the following strategy:

• Only the latest version of each file is stored in full.

• For each earlier version, RCS records only the difference between it and the subsequent version.

The latest version of an RCS file can be extracted immediately from the versions file. Earlier versions must be reconstructed by examining the differences recorded.

This functionality is implemented with variants of the UNIX diff and patch commands.

---

Using RCS On Larger Projects

Example: Multiple Users

RCS & Make:

• Basic RCS support included in Make.

• Can be used in combination to automate retrieval and building of particular versions of an entire system.

---

Limitations of RCS

RCS manages changes only within a file, not to a directory structure. Between versions of a product:

• Files (and directories) may be created or removed.

• Files may be moved.

Everyone working on an project managed by RCS must share access to a common file system. This is often not possible if the collaborators:

• work for different organisations; or

• are geographically distant.

Such situations are common for open-source projects.

The Concurrent Versions System (CVS), built from RCS, addresses these issues. All the COMP2100 materials (lecture notes, lab instructions, assignments, project and other source code etc.) are managed using CVS.

[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]