Improving the treatment of external libraries

Background

Sometimes Cactus code needs to call code in libraries external to Cactus. In order to ensure that these libraries are available to Cactus, each is represented by a Cactus thorn. These thorns perform the following functions:

1. Provide configuration variables for the user to use in their option lists to specify the location of the library on the machine. Sometimes this is as simple as <lib>_DIR = /path/to/lib, but sometimes additional options need to be set, for example if the lib and include directories are in nonstandard locations in relation to the base library path. The external library thorn translates the user's settings for these variables into compiler and linker options which are then used by Cactus when compiling and linking.
2. In the case that the user doesn't specify the location of the library, the thorn attempts to locate the library in some standard locations.
3. As a last resort, or if requested by the user, the thorn will build a version of the library and install it in the configuration directory. For this reason, the thorn usually contains a distribution tarball of the library which is extracted and compiled during the Cactus configuration (CST) stage. Sometimes there is also a patch which is applied to the source of the library. Having the libraries built as part of the configuration ensures that all the libraries needed are always available even if they have not been installed on the machine, but adds a significant overhead to compilation time.

Problems with the existing mechanism

At present, the logic for performing all of the above is implemented in configure.sh scripts in each library thorn. This logic can be quite subtle and involved, and it is desirable for this to be implemented in a central location in a careful and correct way, rather than being duplicated for each library thorn.

Requirements

Collecting together the behaviour required by library thorns, such a mechanism needs to make it straightforward to do the following:

• Provide a variable, <lib>_DIR which either:
  • points to the library installation, in which case the thorn checks that the library in this location is usable and uses it if this is the case, otherwise compilation is aborted;
  • is BUILD (caseless), in which case the thorn builds the library and uses that version;
  • is NO_BUILD (causeless), in which case the thorn searches for a version on the system and uses that, unless it cannot be found, in which case the compilation is aborted;
  • is unset, or is the empty string, in which case the library is first searched for, and if not found, is built (we could have a synonym AUTO (caseless) for this, to make it explicit)
• Provide variables which point to the include and library directories, but by default set these variables to <lib>/include and <lib>/lib.

Questions

• How should the user get the behaviour of setting <lib>_DIR to point to a directory, i.e. explicitly using a specific installation, if there is no such directory, and the include and lib dirs need to be specified separately? Maybe setting any of these three variables (<lib>_DIR, <lib>_INC_DIRS and <lib>_LIB_DIRS) should trigger using exactly that version of the library.