In Section 3.2 we saw how you would bootstrap and build the entire tree, building each component's dependencies before building the component itself.
If, on the other hand, you wish to build only one component, because you wish to install the latest and greatest version of some application, or because you want to work on the CVS version, then you can do that without, in principle, building the entire code collection.
The component directories are organised so that you can build a component from a CVS checkout by moving to the component's directory and giving the sequence of commands:
Before you can do this, however, you will have to do a little preparation, and there are two cases.% ./bootstrap % ./configure % make % make install
One of the functions of the ./bootstrap script
is to regenerate the ./configure script if
necessary, since it is not checked in to the repository.
This requires that the Starlink-specific autotools are in
your path, and so you must first install these
`buildsupport' tools if they are not installed
already.
Instructions for that are below.
There are two cases next. The first is where you currently have a built and installed Starlink system which you either built yourself earlier, or which you installed from a Starlink distribution (note: a Starlink CD distribution dating before 2005 doesn't count here -- though the applications and libraries are essentially the same, the distribution and building arrangements changed radically). The second case is where you are only interested in one component, but are starting from scratch, without a pre-existing distribution (of course, once you successfully complete the second case, you are in the situation where the first case applies).
Case 1 -- pre-built Starlink system: This is the easy one. You need check out only the component of interest (see Section 2.7.2 for notes on that).
STARCONF_DEFAULT_STARLINK to point to the top
of the existing tree, which might be /star or
its equivalent.STARCONF_DEFAULT_PREFIX to
point to the same place if you want to install your new
versions there, or to a different location if you want to
install them separately../bootstrap as above,
and have these locations baked in to the configuration as
the defaults.Alternatively, you can control these two locations at
configure time, after you have run
./bootstrap. You control the installation
location with the --prefix option and the
location of the Starlink tree either with the
STARLINK environment variable or, better, with
the --with-starlink option. Although the use
of the STARLINK variable is supported, it
involves less (easily forgettable) defaulting if you use the
--with-starlink option instead. See Section 2.1.5 for details. Having said this,
setting the STARCONF_DEFAULT... variables is
probably preferable, since you don't then have to remember
to supply the options if you run ./configure
again.
Case 2 -- building from scratch: This
isn't actually much more complicated, but does take a little
longer. You need to check out all of the components that
your component depends on; since there is (currently) no
automatic way to discover what this set of components is, in
practice you might as well check out the whole repository. Since
you don't have a pre-built Starlink directory available,
then you will have to build all or most of the tree, before
the component you're interested in can be built. In this
case, follow the instructions in Section 3.2
-- which include setting the
STARCONF_DEFAULT_... variables to suitable
values -- but instead of finishing with make
world in step 9, do make
/mystar/manifests/cpt, where /mystar is
the location you have chosen for the installation tree (as
specified in STARCONF_DEFAULT_STARLINK), and
cpt is the component you are interested in.
This will build and install in turn each of your component's
dependencies, and then the component itself.
If you are doing this because you want the latest and greatest version of a particular component, then you are finished.
If you are doing this because you want to do development
work on the component, then you might well want to keep the
functioning version separate from your development version.
In this case, you need to go through this procedure once
with STARCONF_DEFAULT_STARLINK and
..._PREFIX having the same values, as above.
Next, you change to the component's directory, and either
bootstrap your development component a second time, with
STARCONF_DEFAULT_PREFIX set to a separate
installation location (you are now in the situation where
case 1 applies, above, and you can give the comments
./bootstrap; ./configure; make); or else re-run
./configure with its --prefix
option set to point to that alternative location (the first
mechanism simply sets the default for the second, and is
probably preferable for the reasons mentioned above).
Note that part of the function of the
./configure script is to find the location of
important files and freeze them in to the Makefile. Thus
the STARLINK variable is ignored after
configure-time, so that you cannot, in general, change the
STARLINK variable or change your path, and have
new binaries picked up.