Appendix B
The relationship with the GNU autotools

The build system is based heavily on the GNU autotools, autoconf, automake and libtool. Each of these is checked in to the CVS repository, and built and installed during the top-level ./bootstrap process. Run the commands with the –version option to see the actual installed version.

The checked-in libtool is an unmodified libtool distribution.

The Starlink autoconf is based on version 2.59, with additions to support preprocessable Fortran; these modifications have been submitted to the autoconf maintainers, so it is hoped that these will become part of the autoconf distribution, at which point the Starlink autoconf will revert to being an unmodified one.

The additions are the macros which start AC_... described in Sec. A.

The Starlink automake is a more heavily modified version of automake. There are a few generic changes to support the added Fortran autoconf macros, but the majority of the changes are in the service of Starlink’s specific requirements. They are summarised here.

• Addition of the MONOLITHS and TASKS primaries: These function rather like the PROGRAMS primary, in that the the MONOLITHS primary specifies one or more monoliths to install, and the TASKS one or more IFL tasks to associate with it. Like the PROGRAMS primary, each MONOLITHS variable should have a xxx_SOURCES variable associated with it. Starlink automake also emits the makefile rules to compile .ifl files to .ifc files.
• Addition of the stardocs, staretc, starhelp (and so on) prefixes to the DATA primary. Setting these variables has the same effect as giving an argument to the STAR_DOCS_FILES macro (and friends). See Sec. A.33.2.
• Extra LDADD options: In standard automake, the content of the LDADD variables must be a list of extra objects to add to a program, or extra libraries, specified through -l and -L flags. In Starlink automake, you can additionally specify extra libraries using the standard Starlink *_link and *_link_adam commands. You can add to the LDADD variable tokens matching ‘[a-z_]*_link‘ or ‘[a-z_]*_link_adam‘ (that is, a sequence of lowercase letters and underscore), or either of these preceded by exactly $(srcdir)/, which you would need to do only in the case of test code or the case below.

  You cannot include any options or arguments. If you want, for example, ast_link -pgplot, then you should create a local script named, for example, my_ast_pgplot_link (that is, matching the pattern above), which simply invokes the correct link script. In this case, you will have to include the $(srcdir)/ element in the line, so that the script will be picked up from the current directory.

• Starlink automake spots use of the STAR_MESSGEN and STAR_LATEX_DOCUMENTATION macros in the associated configure.ac, and produces appropriate extra build rules in the generated Makefile.in. If the STAR_MANIFEST_DIR is to be substituted by autoconf, then Starlink automake adds support for installing manifests to the generated makefile.
• Default strictness: Starlink automake adds the –startree strictness level to the default –foreign, –gnu and –gnits. At present, it is almost indistinguishable from –foreign, and is the default (the default for GNU automake is –gnu strictness – see also Sec. C).
• All of the installation rules have been modified to recognise the presence of the MANIFEST makefile variable, and if it is set true, to include the path to the installed file in the output of the command. The modified install target manages this variable. The makefile ‘install’ target has been modified to create and install such manifests by default.
• The missing script which is installed as part of Starlink automake respects the MISSING_SUPPRESS_RUN environment variable.
• The package version is reported as 1.8.2-starlink rather than plain 1.8.2.