Cactus should know more about allowed configuration options

[Ian Hinder]

Currently, thorns can specify which configuration options their configuration scripts use in their configuration.ccl file. Cactus itself also reads a certain set of options. There should be a list of such options, and Cactus could warn or abort if unrecognised options are included in an optionlist. This would help to avoid user error where options are misspelled or omitted.

Maintaining such a list would also help with documentation: we could ensure that each such option was documented.

Keyword:

[Ian Hinder]

Additionally, the default value of each option should be defined, to avoid inconsistent and buggy implementations of these defaults by thorn configuration scripts and/or Cactus.

For thorns, the possible options are currently listed under the capability definition. For example, for ExternalLibraries/HDF5, we have:

PROVIDES HDF5 { SCRIPT configure.sh LANG bash OPTIONS HDF5 HDF5_DIR HDF5_INSTALL_DIR HDF5_ENABLE_CXX HDF5_ENABLE_FORTRAN ZLIB_DIR LIBSZ_DIR LIBZ_DIR }

Assuming that we want to keep this syntax, an obvious way to include the default value would be to suffix each option with "=<defaultvalue>". For example,

PROVIDES HDF5 { SCRIPT configure.sh LANG bash OPTIONS HDF5=BUILD HDF5_DIR HDF5_INSTALL_DIR HDF5_ENABLE_CXX=yes HDF5_ENABLE_FORTRAN=yes ZLIB_DIR LIBSZ_DIR LIBZ_DIR }

The absence of a default means that the default value is the empty string. Note that this is different from the option being unset. I think there should be no distinction between the option being unset and it being set to the empty string, as maintaining such a distinction will likely cause confusion.

In order to maintain a list of valid options, as per the original ticket description, we could add them to the Cactus/src/configuration.ccl file. This could either be within a capability called "CACTUS" which all thorns automatically require, or we could introduce an additional syntax for this.

Once we have included all the options used by Cactus, we could eventually make it an error to include an unrecognised option in an option list file.

As a side benefit, we might also address #332 by removing all recognised options from the environment within the top-level Makefile to avoid conflicts with environment variables. Alternatively we could warn about them, so that the user can fix the problem.

[Ian Hinder]

We could also define the convention that options with default values of "yes" or "no" are treated specially, and always converted to a canonical boolean form.

[Erik Schnetter]

It is customary to set options on the command line when configuring, or to set them in the environment before calling configure. We may want to continue to allow this for Cactus to remain compatible with other users of autoconf. This would mean that we cannot clean the environment as suggested above.