STARCONF_DEFAULT_PREFIX
and
STARCONF_DEFAULT_STARLINK
Two very important variables are
STARCONF_DEFAULT_PREFIX
and
STARCONF_DEFAULT_STARLINK
. The first is the default
installation prefix of the software you are building; the second is
the location of a currently built Starlink tree, which will be used
for applications and include files if they are not found under
STARCONF_DEFAULT_PREFIX
.
The value for each of these was frozen when starconf was itself
built and installed, most typically at the time of the tree-wide
bootstrap, and you can see the values for these with the command
starconf --show STARCONF_DEFAULT_PREFIX
for example. You
can also see the results of this configuration in the
./configure
script itself, as the command
./configure --help
indicates within its output where
material will be installed by default. It is not unreasonable to have
more than one starconf installation, depending on your path, if you
wish to have different frozen-in defaults here. The value of each of
these two variables is typically something like
/star
.
It is important to emphasise that these parameters are frozen when starconf is built, and their values are ignored when a component is itself bootstrapped. If you need to change either value, then there are two ways you can do this.
The first, much more common, way is to provide the
--prefix
option when you run ./configure
in
a component (this overrides the frozen-in value of
STARCONF_DEFAULT_PREFIX
), or you can set the
STARLINK
variable as a ./configure
argument line
(or less securely default it from the environment, see Section 2.1.5 for discussion), overriding the frozen-in
value of STARCONF_DEFAULT_STARLINK
.
Specifying --prefix
or STARLINK
each time you run
./configure
might be troublesome when you are working on
a component's configuration script, especially as doing this
inconsistently would produce very confusing
results. You might want
to do this if you are working on a repository branch, and so want
built material from the current directory to be installed in one
branch-specific place, while using a Starlink tree based on the trunk.
You can default this on a per-directory basis by using a m4 back-door.
Create a file acinclude.m4
in
the directory in question, and include in it a line like:
(orm4_define([OVERRIDE_PREFIX],[/my-branch/star])
OVERRIDE_STARLINK
to override that variable). Then
run ./bootstrap
, which invokes `autoreconf' in turn, and
the generated ./configure
file will have the named directory
as its default prefix. This method is in principle
fragile, and uses a partly-deprecated autoconf interface,
and so is not guaranteed to work for all time. It is at present adequately
robust in practice, however, and so is a respectable technique as long
as you are aware that it is to some extent a rather special effect.In general, however, we recommend that you do not adjust
--prefix
, and that you leave the
STARLINK
variable unset. Also, since they are ignored at
all times except when the whole tree is being configures, it might be
wise not to have the STARCONF_DEFAULT_...
variables set, which could trick you into believing that they are
(not) having some effect.