If you wish to build the entire tree after a fresh
checkout, you do so at the top level, using the
./bootstrap script and Makefile.in
located there. Neither of these is a `standard' one, as
installed by starconf or Starlink automake.
These instructions are echoed in the file
README in the top-level directory.
The complete procedure for a full build is as shown
below, for an installation into the notional directory
/local/star; explanations follow.
1% cvs -d :ext:username@cvs.starlink.ac.uk:/cvs checkout . 2% unset STARLINK INSTALL 3% export STARCONF_DEFAULT_STARLINK=/local/star 4% export STARCONF_DEFAULT_PREFIX=/local/star 5% rm -Rf /local/star 6% PATH=/local/star/bin:/local/star/buildsupport/bin:...??? # see note 7% ./bootstrap ... a few harmless warnings, and miscellaneous other chatter ... takes quite a while 8% ./configure -C ... mucho blah-blah-blah 9% make world ... etc 10% ls /local/star/manifests adam automake ems hlp messgen par sae star2html task ams chr fio lex messys parsecon sla starconf atimer cnf hds libtool misc pcs sock string autoconf dtask hdspar mers msp psx sst subpar
Line 1: check out the entire collection from the
repository. See Section 2.7.2 for hints on
how to be more discriminating, which may be desirable, since
not everything in the repository is controlled by this
bootstrapping build, most notably the contents of the
java directory.
Lines 2-4: unset the STARLINK and
INSTALL variables, and
set the two starconf variables as
shown.
For a whole-tree
build, these two should have the same value, to ensure that
the build uses only tools and libraries which have been
built at an earlier point in the build. For fuller details
of these variables, and more information about controlling
the bootstrapping process, see Section 3.5. This example shows sh-style
commands for manipulating the environment; you will of
course use the csh-style setenv and
unsetenv if you're using that shell.
Also at this point you should review any other environment
variables that might affect the build. For example, the
variables F77, FC and
CC will force the build system to use the
specified compilers. In particular, the default IRAF
installation sets the F77 variable to be a
script which works happily in most cases, but which will
_not_ work with libtool, and will cause the build to fail
with opaque error messages about being `unable to infer
tagged configuration'. Unless you do wish to force certain
compilers to be used, it is probably better to unset these
variables before building the software. Try
./configure --help for a list of `some
influential environment variables', and Section 2.1.5 for more discussion of this
issue.
Line 5: the directory where the components are to be
installed can be empty, and need not exist at the
start. It doesn't matter if this is not empty in fact,
since most of the installation tree is not examined by the
build. The only exception is
/local/star/manifests, since the files in this
directory control what is actually built -- see the notes
for line 9.
Line 6: put /local/star/bin and
/local/star/buildsupport/bin in the
path.
Make sure that there are no Starlink binary
directories elsewhere in the path: running which
messgen (for example) at this point should find
nothing.
Line 7: run the ./bootstrap script. This
configures, builds and installs the `buildsupport' tools --
the autotools plus the starconf application -- then
recursively runs the bootstrap code in a selection of the
directories beneath this one. The directories the bootstrap
recurses into, in this directory and its children, are those
listed in a AC_CONFIG_SUBDIRS macro in
configure.ac. After this, you should be able
to do
% which autoconf
/local/star/buildsupport/bin/autoconf
% autoconf --version
autoconf (GNU Autoconf) 2.59
...
%
Line 8: configure the entire tree (the -C
option indicates that configure should cache its results,
speeding up the process). This configures this
directory and recurses into the children named in
AC_CONFIG_SUBDIRS in this
configure.ac and those below it.
If you will need to give ./configure some help
to find include files and libraries, you might try
setting the CFLAGS or LDFLAGS
variables in the environment, in the manner described in
Section 2.1.5. Note, however, that this is
not a recommended practice.
Line 9: build the entire tree, using the make
world target described in Section 3.1. The make builds all the
components in an order which ensures that each component is
build after the components it depends on, as declared in
STAR_DECLARE_DEPENDENCIES
invocations in
those components' configure.ac files. The set
of dependencies can be examined (if you're interested) in
the file componentset.xml, which is built up
from the various directories' component.xml
files, as reprocessed into
Makefile.dependencies.
Note that the
dependencies are expressed as dependencies of components'
manifest files on each other, and the top-level
makefile is written so that each component is built with the
pair of commands make; make install,
which builds the component then installs both it and its manifest.
Thus, if you need to ask
for a particular component, foo, to be built, you can do so from
the top-level directory with make
/local/star/manifests/foo.
Line 10: after the make, a manifest is installed for each of the built components.