The Starlink build system consists of
autoconf automake and
libtool;starconf system and the scripts at the top level of the
Starlink source tree; and<http://wiki.starlink.ac.uk/twiki/bin/view/Starlink/BranchingPolicy>
and
<http://wiki.starlink.ac.uk/twiki/bin/view/Starlink/CvsTagging>
(you will currently need a wiki account to see these pages).The repository is on the machine
cvs.starlink.ac.uk -- see
Section 2.6 for further details.
The build system is intended to cover two main cases.
Firstly, it covers the problem of building code directly from
the CVS repository, both when building the entire software set
from scratch (as during the nightly test build for example),
and when working on a development version of a particular
component, within the context of an otherwise built software
set. This includes the problem of abiding by long-standing
Starlink conventions on documentation, auxiliary tools and
installation locations. The build system at present is
concerned primarily with the `classic' applications, which are the
large volume of legacy Starlink code which, though it is no
longer being developed, must still be maintained and be
buildable by the community. It has no contact with the large
volume of Java code, apart from having the same tagging and
branching conventions, since the building of the Java
applications is currently completely handled by the
ant system.
Each component in the CVS repository is intended to be built separately, as opposed to being built only by a make running at the top of the tree. Many components require other components to be installed, and the role of the top-level makefile is to manage these dependencies, when it is necessary to build the entire tree from scratch. After a fresh CVS checkout, and presuming that any dependencies are in place, each component in the tree should be built with the sequence of commands
The `install' target generated by Starlink automake installs the component as usual, but additionally creates a manifest file which is then installed in the% ./bootstrap % ./configure % make % make install
manifests/ subdirectory under the Starlink
installation directory. The building of the whole tree from
scratch is described in Section 3.2, and the
procedure to build a single component, though little more
complicated than described here, is discussed in more detail
in Section 3.3. You should read both of
these sections before trying the commands above.Secondly, the build system handles the construction of portable source-code sets -- distribution tarballs -- so that individual components can be built by users, from source, as straightforwardly as possible. Since we are using the GNU autotools, much of this functionality comes for free, and we simply have to do the relatively small amount of configuration work required to ensure that the source set is complete (rather than requiring non-distributed build tools) and has clearly expressed dependencies between packages. It is an absolute requirement that the build process for users must consist of no more than
with the usual options available for% ./configure % make % make install
./configure
and the usual relocations available for GNU-style makefiles.
This document does not discuss building from a distribution
tarball in any more detail than this, since there is really
very little more detail to discuss.The system does not cover the precise mechanism by which these tarballs are distributed to users, nor the means by which they are informed of, or helped to satisfy, the dependencies between components; but in generating manifests and assembling the component dependency graph, it provides the information which such a distribution portal would need.
In other sections of this document, we discuss the tools used to support developing within the CVS tree, including the specific starconf tools and an overview of the GNU autotools autoconf, automake and libtool (Section 2); we discuss the procedure for building applications within the repository (Section 3); and we describe the process of adapting a currently working package to the build system's conventions (Section 4).