2.2 Starconf, and the Starlink autoconf macros

The starconf application does some of the work of ensuring that your build directory is correctly organised. It does the following:

• ensures that you have a ./bootstrap script;
• runs the starconf-validate application to check that your configure.ac and Makefile.am files look at least plausible by checking, amongst other things, for the presence of a STAR_DEFAULTS invocation in the former, and to check that the right files have been checked in to the repository;
• creates the script ./starconf.status, which allows you to inspect some of the starconf parameters.

The ./bootstrap script is `owned' by starconf, and you should not change it, since it will be overritten by starconf if a newer release of starconf includes an updated bootstrap script. If you do have some pressing reason to change it, then remove the word `original' from the second line of the bootstrap file, which signals to starconf that it should leave the file untouched. The standard bootstrap script:

• runs starconf, using ./starconf.status if necessary to find the path to the program;
• bootstraps any subdirectories named in the AC_CONFIG_SUBDIRS macro within configure.ac;
• runs autoreconf to regenerate configuration files if necessary.

You need to run starconf explicitly only once, when you first prepare a directory for configuration. The ./bootstrap file which this creates itself runs starconf, so that each time you run the bootstrap script, you run starconf also. This has no effect unless either the bootstrap script or the macro set has been updated in the starconf installation, in which case starconf will propagate the updates to your directory. The ./starconf.status script should not be checked into the repository. The command starconf-validate (which is invoked by starconf in passing but which may be invoked explicitly also) will tell you what should and shouldn't be checked in.

You might on other occasions run the ./starconf.status script. You will do this firstly to query important locations, such as the location of the starconf templates:

% ./starconf.status --show buildsupportdata
/export3/sun/buildsupport/share

These variables are fixed for a particular installation of starconf (you can in principle have more than one installation of starconf, and choose which one to invoke, but there is unlikely any need for that).

Two very important variables are STARCONF_DEFAULT_PREFIX and STARCONF_DEFAULT_STARLINK, discussed in Section 2.2.1 below.

A companion to the starconf application is the starconf-validate application. When run, this examines the current directory, checking that all required files are present, and checking that you have the correct files checked in to the repository. The command starconf-validate --help shows which files are in which category. Note that this applies only to directories which are fully Starlink applications -- those in the libraries and applications directories; components in the thirdparty tree, on the other hand, have some starconf features such as a component.xml file, but are not valid according to starconf-validate; also `bundle' directories such as libraries/pcs, which have no actual code in them, are not valid in this sense.

There are templates available for the most important starconf files. See Section 2.2.3.

The final component of the starconf system is the file component.xml. This is an XML file containing information about the particular component in the directory. The information in this file is redundant with some of the information you specify in configure.ac, and so the best way to ensure the two are consistent is to configure component.xml from configure.ac. To this end, there is a template component.xml.in file in the starconf `buildsupportdata' directory. When you are preparing a directory to be build with the Starlink tools, copy this template-component.xml.in into the current directory under the name component.xml.in, and fill in those field which are not configured. Remember to uncomment the elements you fill in! See Section 2.2.4 for details. The files component.xml and component.xml.in should both be checked in.

• 1. STARCONF_DEFAULT_PREFIX and STARCONF_DEFAULT_STARLINK
• 2. Components
• 3. File templates
• 4. The format of the component.xml file