Next Up Previous Contents
Next: 2.2.2 Components
Up: 2.2 Starconf, and the Starlink autoconf macros
Previous: 2.2 Starconf, and the Starlink autoconf macros
[ID index][Keyword index]

2.2.1 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:


m4_define([OVERRIDE_PREFIX],[/my-branch/star])
(or 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.


Next Up Previous Contents
Next: 2.2.2 Components
Up: 2.2 Starconf, and the Starlink autoconf macros
Previous: 2.2 Starconf, and the Starlink autoconf macros
[ID index][Keyword index]
The Starlink Build System
Starlink System Note 78
Norman Gray, Peter W Draper, Mark B Taylor, Steven E Rankin
11 April 2005. Release snapshot: $Revision: 1.116 $. Last updated 28 May 2006