NOTE: this section is subject to a little change. The guidance in this section is to some extent subject to change as we get more experience including third-party sources into the tree.
If an application needs to rely on a non-Starlink
application, and especially if it relies on a modified
version, then the sources for that application should be
checked in to the thirdparty/ part of the
tree.
There are two stages to this. Firstly we have to import a distribution version of the software, and secondly we have to bring it in to the Starlink build system.
The example here is the GNU m4 distribution, which is one of the buildsupport tools necessary on Solaris, which has a non-GNU m4 (autoconf relies on language extensions in GNU m4, which is therefore required). The first step is rather mechanical, the second better introduced by example.
First, we get and import the sources (see the fuller details in the CVS manual):
% cd /tmp
% wget http://ftp.gnu.org/pub/gnu/m4/m4-1.4.tar.gz
% tar xzf m4-1.4.tar.gz
% cd m4-1.4
% cvs -d :ext:username@cvs.starlink.ac.uk:/cvs import \
-ko -m "Import of GNU m4 1.4" \
thirdparty/fsf/m4 FSF m4-1-4
The -ko option turns off any keyword expansion
for the newly-imported files. Thus they will retain the
values they had when they were imported. This appears to be
the practice recommended by the CVS manual, though it is not
absolutely clear that it is best, and this should not be
taken as a firm recommendation.
The thirdparty/fsf/m4 argument is the location
of the new component within our repository, the
path to which will be created for you if necessary. FSF --
the `Free Software Foundation' -- is the `vendor' in this
case, and this is used for the location within the
thirdparty/ tree as well as the next CVS
argument. CVS uses this vendor argument as the name of the
branch this new import is nominally located on.
Finally, this import command tags the imported files with the tag you give as the last argument. This should use the same convention as other tags within the Starlink repository, namely the component name and version number.
Note that we import a distribution tarball of the
source, namely one including the configure
script and any other generated files. This is because we
cannot reliably bootstrap the original sources if they, for
example, and also so that we can reliably track any future
releases of the tarball. Even if the component has a public
CVS archive, resist the temptation to import a snapshot of
that.
Now that the source set is in the repository, you can go back to your checkout tree and check the new component out:
% cd <checkout-tree>
% cvs -d :ext:username@cvs.starlink.ac.uk:/cvs co thirdparty/fsf/m4
[blah...]
% cd thirdparty/fsf/m4
% cvs status -v configure.in
===================================================================
File: configure.in Status: Up-to-date
Working revision: 1.1.1.1
Repository revision: 1.1.1.1 /cvs/thirdparty/fsf/m4/configure.in,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: -ko
Existing Tags:
m4-1-4 (revision: 1.1.1.1)
FSF (branch: 1.1.1)
FSF. Any files we add to
this component, and any files we modify, will go on the
trunk.What you do next depends on how easy it is to configure the
new component. We'll look at three examples,
the m4 component, containing the GNU version of m4,
the cfitsio component, containing the HEASARC
FITS library, and
the tclsys component, containing a distribution
of Tcl.
m4 configuration is quite regular
(as befits a core GNU component), and so admits of
reasonable adaptation in place, by simply editing the
configuration files included in the distribution (and
then, despite what we said above, regenerating the
distributed ./configure script.cfitsio distribution comes with its
own configure scripts, but they are generated using a
rather old version of autoconf, so we want to avoid
touching them. However the build is basically rather
simple, and only a few built files need to be
installed. This component shows how to wrap a
distribution's own configuration in a straightforward
way.tclsys component, on the other hand
comes with its own fearsomely intricate configuration
and installation mechanism, which we want to disturb
(or indeed know about) as little as possible. This
section shows how to wrap such an installation in the
most general way.