CTBUILD is a system for building software packages. Here we describe the design goals (e.g. the requirements). The discussion is divided into the following sections:
The input to CTBUILD is one or more software packages. These packages are collections of code and build instruction files contained within a package directory. The instructions must meet the CTEST interface.
CTBUILD is not allowed to modify or extend the package in any way. The only exception would be if the installer directs output into the package directory.
An installation consists of the products built from one or more packages. These include all the targets defined by CTEST:
The products of some of the targets may depend on those from other targets. These dependencies are shown in parentheses.
CTBUILD must provide a way to create an installation which specifies:
The installation should be self-describing: all the above information should be contained within and obtained from the installation. Once the installation is made, the build products should not depend on the user's environment.
The installation should provide a method by which it can be removed leaving no traces behind. This removal deletes the destination directories an all their files.
CTBUILD provides a method to build all of the products associated with a specified package and target. This is sometime referred to as invoking a target on a package. Each of the products has a well-defined set of dependencies, i.e. files from which it is built.
These dependencies are said to be internal if they are files within the package or products of the package. Any internal dependencies should be constructed automatically.
External dependencies are those outside the package. These may be products of other packages or may be outside the installation (see the following section). These are not generated automatically and the build will generally fail if they are not present.
All dependencies are identified and utilized. When a target is invoked, then the each associated product is checked. Each product is built if it does not exist or is rebuilt if any of its dependencies have changed. Otherwise no action is taken.
A method is provided for deleting all the products associated with a particular package and target. No other products are deleted.
Products may have dependencies outside the installation. Dependencies are found by searching along a path. The path depends on the type of the dependent product (library, object, etc.). The current installation is the first entry on this path. These search paths are attributes of the installation.
Using paths to search for dependencies has some danger. If a product appears in more than one installation, we may find the wrong version. If products are added or removed then the dependency may move to a different file. CTBUILD is required to recognize this change. Any products with this dependency should also depend on the change, i.e. they are rebuilt the next time they are checked.
This change should be discovered automatically if it is within the package. CTBUILD provides a method to regenerate the dependencies which can be used when products are added or removed outside the installation.
An installation generally includes multiple packages which depend on one another. Ideally these dependencies are acyclic but this is not a requirement. The products in one package may depend on the products of another but they may not depend directly on the sources of an external package.
Each package is processed independently. Building a product associated with a target and a package may trigger the build of products associated with other targets for that package but will not trigger the build of products associated with any other package. A rebuild should fail if it requires the build or rebuild of an external product.
Build failures due to unbuilt dependencies within the installation (and the mistaken assignment to files outside the installation) can be avoided by building in the proper order. Note this is not an issue for single packages because they are required to build their own internal dependencies.
These failures may be avoided by using the well-defined target dependencies. If target C depends on targets A and B, then invoke A and B for all packages before invoking C for any package. The target dependencies are given in the list of targets above.
If the package dependencies are acyclic, then the packages may be built completely (all targets invoked) in dependency order. This is a very useful mode for package development.
This version of CTBUILD does not provide any explicit support for combining installations, i.e. extending one installation with another. However, the external product paths may be used to achieve this effect.