In general, the details of making distributions are outside the (current) scope of this document. However there is one aspect we can usefully mention, since it interacts with the buildsupport tools which configure the distribution.
Normally, when you ./bootstrap a directory,
it arranges to install it by default in a location
governed by starconf (see Section 2.2 for
details). Since this default is a location on your local
machine, it might not be appropriate for a distribution
tarball. In that case, you will probably want to ensure
that the built distribution will install into
/star (or /usr/local perhaps).
There are multiple ways you can do this.
If you are doing this for a complete tree, with the intention of building all the software and rolling distribution tarballs with the result, then the procedure you should use is as follows.
/stardev
but the default Starlink directory to remain /star. Set
these as the STARCONF_* defaults.
If this directory really is just% export STARCONF_DEFAULT_PREFIX=/star % export STARCONF_DEFAULT_STARLINK=/star
/star then these
settings could in principle be omitted and the variables simply left
unset, since /star is the default for both, but declaring
them explicitly avoids ambiguity. The directory mentioned here need
not exist or be writable./tmp/star as an example. Since this
directory will receive the the buildsupport tools, and other tools
built during the build, it will need to be included in your PATH.
% PATH=/tmp/star:$PATH
/star.
% ./bootstrap --buildsupport-prefix=/tmp/star
STARCONF_*
defaults.
This will install the components into% ./configure -C --prefix=/tmp/star --with-starlink=/tmp/star
/tmp/star, with
later components using tools installed there earlier, but with the
./configure scripts within those components
written so that they will still install in /star by
default.The manifests will end up in% make world
/tmp/star/manifests.After this process has completed, if you go to a built component
and make a tarball using make
dist, then this tarball will install in /star by
default, which you can check using ./configure --help.
If, on the other hand, you wish to create a distribution tarball of a single component, then you do not have to reconfigure the entire tree to do so (fortunately).
The more robust way is to create a special set of
buildsupport tools which have the desired directory as
their default prefix. Say you want the distribution to
install by default
in /star, but have these special buildsupport
tools installed in /local-star/makedist (for
example) . Do that as follows:
% STARCONF_DEFAULT_PREFIX=/star ./bootstrap --buildsupport \
--buildsupport-prefix=/local-star/makedist
env ... on csh-type shells; you would
typically specify STARCONF_DEFAULT_STARLINK here,
too).. Setting the two
STARCONF_* variables is actually redundant, here, since
both have /star as their default, but it does no harm and
can make things usefully explicit.At this point, you can check out the appropriate version
of your software (probably via a CVS export of a
particular tag), put this
/local-star/makedist/bin in your path
(rehashing if you are using csh), and call
./bootstrap; ./configure; make dist as
usual. The command ./configure --help will
show you the default prefix for this
./configure script.
An alternative way is to use the
acinclude.m4 method described
in Section 2.2.1, setting
OVERRIDE_PREFIX to /star (for example).
When you run ./bootstrap after that, the given prefix
will be used instead of the prefix baked into the installed
buildsupport tools.
That is, to create a distribution of component
foo, located in libraries/foo in
the repository, you should tag the source set
with a suitable release tag, such as
foo-1-2-3, and then, in a temporary
directory, do the following:
This will leave a tarball such as% cvs -d ??? export -r foo-1-2-3 libraries/foo % cd libraries/foo % echo 'm4_define([OVERRIDE_PREFIX],[/star])' >acinclude.m4 % ./bootstrap % ./configure % make dist
foo-1.2-3.tar.gz in the current directory.