Next Up Previous Contents
Next: 3.5 Bootstrapping without building: configuring starconf and the autotools
Up: 3 Building applications and libraries
Previous: 3.3 Building a single component
[ID index][Keyword index]

3.4 Building monoliths

As illustrated in Section 2.1.2, you can build monoliths in an analogous way to the way you build programs, by declaring the monoliths as the value of the bin_MONOLITHS variable.

Along with the bin_MONOLITHS variable, a Makefile must also declare a set of tasks using the TASKS primary, and this set will be empty if the monolith is an ATASK. If a monolith foo has a set of tasks a and b, then this declaration will look like this:


bin_MONOLITHS = foo
foo_TASKS = a b
That is, the tasks are listed without any .ifl extension.

The foo_TASKS primary indicates to automake that there will be .ifl files in the local directory corresponding to each of the tasks in the monolith, that these .ifl files should be distributed, and that the appropriate extra links should be made, in the binary directory, when the monolith is installed. The tasks variable might also be used in the foo_SOURCES variable to declare the dependence of the monolith on the Fortran files corresponding to the tasks (it would be possible to automake to have inferred this last step, but it seems clearer overall to have this dependency at least made explicit). Automake permits the usual Makefile variable rewritings, so that if you have a Fortran file corresponding to each task, then this set is $(foo_TASKS:=.f), which might be useful.

The generated Makefile.in will install each of the task .ifc files, plus the monolith .ifc file. The monolith .ifl file is constructed by appending each of the task .ifl files, wrapped in begin monolith and end monolith, and this generated .ifl file should not be included in the repository or the distribution.

If you are building an ATASK, then the task is the same name as the program. Indicate this by omitting the ..._TASKS variable:


bin_MONOLITHS = foo
# no variable foo_TASKS, since foo is an ATASK
(the extra comment is useful to help document the slightly non-obvious construction here). In this case, the only .ifl file is that for the ATASK. The makefile makes sure that this .ifl file is distributed, so the file should either exist, or have a rule in the Makefile.am.

The MONOLITH primary allows the prefixes bin, check and noinst, rather like PROGRAMS.

In order to use the monolith support, you must request this by including the declaration STAR_MONOLITHS in the configure.ac file, most rationally near the AC_PROG_CC-style declarations.


Next Up Previous Contents
Next: 3.5 Bootstrapping without building: configuring starconf and the autotools
Up: 3 Building applications and libraries
Previous: 3.3 Building a single component
[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