1. Build Managers

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build
  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress
• incremental
  • allow focused/partial builds
• flexible
  • allow for a variety of build actions
  • on a variety of platforms
• configurable
  • permit the management of multiple artifact configurations

2. Some Sample Project Builds

Here are some of the project builds I have had to automate in the opening weeks of one semester:

2.1 Student Programming Assignment

Set up to allow students to easily compile code for an assignment.

• Build each missing or out-of-date .o file by compiling a corresponding .cpp file.

  • Record which .cpp files and .h files were used during the compilation so that future builds can determine what would future source code changes would make this .o file outdated.

• Link all .o files to produce an executable

2.2 Code Annotation Tool

The code annotation tool is a program I use to convert C++ and Java code with optional markup comments like this into this.

Building the Code Annotation Tool

The steps involved in building this tool are:

1. Run the program jflex on each file in src/main/jflex, generating a pair of .java files that get placed in src/main/java

2. Compile the Java files in src/main/java, placing the results in target/classes

3. Compile the Java files in src/test/java (using the target/classes compilation results, placing the results in target/test-classes.

4. Run the JUnit tests in target/test-classes.

5. If all tests pass, package the compiled classes in target/classes into a .jar file.

It’s worth noting how many of the steps in this project build are not simply compile and link steps.

2.3 Class Assignment Setup

Class Assignment Setup

In preparing to release a programming assignment to a class, the steps are

1. Setup:
   • Copy all of the files that I will provide to students from a Public directory into a Work directory.
   • Copy all of the files from my Solution directory into that Work directory
2. Build solution
   • Compile any .cpp files in the Work directory
   • Link the resulting .o files.

3. Run the executable produced in the last step on each test*.dat in the Tests directory, capturing the output as a corresponding .out file.

4. Copy all source code from the Work directory into a winWork directory.

5.Use a cross-compiler to compile and link the .cpp files in winWork into a Windows executable

1. Install:
   • Copy the two executables and the contents of the Public directory into a release area accessible to students.
   • Set the permissions on the copied files so that they can be accessed.
   • Copy any .html and graphics files for the assignment to the course website.

2.4 Posting Slides and Lecture Notes

The lectures notes for this course are prepared through a process:

1. Setup
   • Convert all graphics to PNG or PDF:
     • For each GIF file in the directory with no corresponding PNG file, run convert to produce a PNG.
     • For each FIG file in the directory with no corresponding EPS file, run fig2dev to produce an EPS.
     • For each Dia file in the directory with no corresponding EPS file, run dia to export as EPS.
     • For each EPS file in the directory with no corresponding PDF file, run epstopdf to create a PDF. \eii Annotate source code:
     • For each C++ or Java file with no corresponding HTML file, use the code annotation tool to generate an HTML file.
     • For each C++ or Java file with no corresponding TeX file, use the code annotation tool to generate an TeX file.
2. Generation: For each desired document output format,
   • Run a preprecessor on the markdown file containing the document source.
   • Run a markdown processor to generate HTML.
   • Apply an XSLT stylesheet to add format info and to split the document into slides/pages.
3. Deployment:
   • Synchronize this directory with the corresponding directory of the website, or
   • Prepare a zip file with the contents of this directory that can be uploaded to a remote webserver (e.g., Blackboard).

3. Types of Build Managers

Why Not Just Write a Script?

We could simply write a “simple” script to perform each of the steps in sequence …

#!/bin/sh
cp Public/* Work/
cp -f Solution/* Work/
g++ -o Work/program Work/*.cpp
find Tests -name 'test*.dat' -exec sh runTest.sh Work/program {} \;
mkdir WinWork
cp Work/*.h Work/*.cpp WinWork
x86_64-w64-mingw32-g++ -o WinWork/program WinWork/*.cpp --static
mkdir $releaseDir/bin
mkdir $releaseDir/bin/Linux
cp Work/program $releaseDir/bin/Linux
mkdir $releaseDir/bin/Windows
cp WinWork/program $releaseDir/bin/Windows
chmod 775 $releaseDir/bin/*/program
cp *.html *.png $website/

Scripting

But how does this fare according to our earlier build manager goals?

• easy to use? Y

• easy to set up for a given project? N

• efficient in performing the build?
  • avoid redundant/unnecessary actions N
  • detect and abort bad builds in progress ?
• incremental?
  • allow focused/partial builds ?
• flexible?
  • allow for a variety of build actions N
  • on a variety of platforms N
• configurable?
  • permit the management of multiple artifact configurations ?

3.1 IDE project managers

Most IDEs come with a built-in project manager.

• typically limited to compiling and linking

• maybe some support for packaging Compare to our \hyperlink{studentProg}{sample projects}.

3.2 Dependency-Based Managers

Some build managers are based on the idea of a dependency graph:

• Boxes are files.

• Arrows denote dependencies. “A depends on B” means that if B is missing or changed, then A must be (re)generated.

• Labels on arrows indicate the program used to generate the file at the base of the arrow.

Analysis of such a graph facilitates

• efficiency - easy to tell what needs to be rebuilt after a change

• incrementality - can determine required build step for any file, not just the “final” one

make is the canonical example of a build manager of this type.

3.3 Task-Based Managers

Other managers are based on the idea of interdependent tasks.

• Ellipses are tasks (activities). Each task can involve multiple steps.

• Arrows denote success dependencies. “A depends on B” means that A will be run after B and only if task B finished successfully.

This approach facilitates

• ease of setup: usually less detailed than a full file-based dependency graph

• incrementality - can request any intermediate step

ant is based on this approach.