Running the configure script is basically very simple:
./configure. There are, however, options and
arguments which can help you, or catch you out. You can
see the full list of options with the command
./configure --help.
You set the place where the configured component will be installed
with the --prefix option. This names a directory which
will end up with the standard directories bin,
manifests and so on. The default is reported by
./configure --help, and is ultimately controlled by
starconf (see Section 3.5 and Section 2.4; or Section 2.2.1 for a
means of setting it to a per-directory default, which can be useful in
certain circumstances).
Because configure's tests potentially take quite a long time to
run, it is possible to cache the results between runs. If you add an
option -C, then these results will be cached in a file
config.cache in the current directory. When you do the
tree-wide configure from the top level, it is important to give this
option, otherwise the configure step takes an unconscionably long
time. When this is happening, the configure runs in subdirectories
use the cache file in the top-level directory, and when you are
running configure in subdirectories, you can use this global cache,
too. If you are in a directory two levels down from the top (say),
then you can configure slightly faster using the command
This reads and updates the given cache file. Sometimes, when things get a little confused, you might need to delete this cache file -- this is always safe.% ./configure --config-cache=../../config.cache
The Starlink autoconf adds a couple of extra standard options.
--with-starlink[=location]location is provided, this does
nothing. This is effectively the default.If a location is provided, it
overrides the STARLINK environment variable which will
be used. Very rarely needed.
Option --without-starlink causes the
STARLINK shell variable to be unset.
Some packages might with to configure themselves
differently in this case.
--without-stardocs--with-stardocs, and so you can disable
this with the configure option
--without-stardocs.A few components have extra options on the
./configure command. For example, the
component docs/ssn/078 (the component which
holds this document) has a --with-pstoimg
option, the value of which must be the full path to a copy
of the pstoimg program, to help in the cases
where this cannot be discovered automatically (this may be
a temporary feature of this component).
All of the components have ``Some influential environment
variables'' listed in
the help message. This will include
at least STARLINK, and in the (very common!) case
of components which include a compiler, an
environment variable such as
CC or
FC
which allows you to override the compiler
which the configure script will find. This is useful
if you want to avoid a default compiler and use a specific
one instead. For example, if you wished to use
the Sun C++ compiler specifically (while on a Sun,
obviously), you would put /opt/SUNWspro/bin
in your path, and set the CXX variable:
or% export CXX=CC # best avoided % ./configure
where the latter is probably preferable, inasmuch as it does not leave this important variable set, in such a way that it can make a difference unexpectedly.% env CXX=CC ./configure # best avoided
Better than either of these is
This doesn't set% ./configure CXX=CC
CXX as an environment
variable, but sets it in a similar-looking way as one of the
./configure arguments. This way is
preferable to either of the above for two reasons:
firstly, it does not leave the
variable set; secondly, this way ./configure
`knows' that the compiler has been overridden, so that if
you are using a configure cache, and
you fail to do this when the directory is
reconfigured, ./configure can warn you of
this, in case this is not deliberate.If you change one of these variables between runs, and
are using a configure cache, then the
./configure script will warn you like this:
To deal with this, simply remove the% ./configure -C configure: loading cache config.cache configure: error: `STARLINK' has changed since the previous run: configure: former value: /somewhere/else configure: current value: /export3/sun configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm config.cache' and start over
config.cache file, check that the environment
variable is indeed set as you wish, and rerun
./configure.You can pass options to the compiler using environment variables,
but you will not need to do this in general, other than
perhaps to set CFLAGS=-g to turn on debugging
in the code you are building. The variables CFLAGS and
LDFLAGS are variables you might potentially set and
export in the environment, for example to point
./configure to software installed in non-standard places
(perhaps you are on a Mac and have installed Fink in /sw
or OpenDarwin in /opt/local, or are on a Sun and have
extra software in /opt). In this case you might set
CFLAGS=-I/opt/local/include and
LDFLAGS=-L/opt/local/lib in the environment to help
configure and the compiler find libraries. Note that this is rather a
blunt instrument, and because you cannot really control where the
respective flags appear in generated compiler commands, you can end up
picking up inconsistent versions of software. That is, this is a
mechanism for getting yourself out of a fix, not a recommended way of
building the software.
The important point of this is that these environment variables
do matter, and implicitly change the
behaviour of ./configure. You should
not have them set in your environment if you don't want
this to happen.
The values you set here act as defaults in the Makefile, and can be overriden at make time by giving arguments to make:
% make 'CFLAGS=-g -I/somewhere/else'