[ET Trac] [Einstein Toolkit] #1042: Cactus should know more about allowed configuration options

Einstein Toolkit trac-noreply at einsteintoolkit.org
Mon Sep 3 08:02:32 CDT 2012


#1042: Cactus should know more about allowed configuration options
--------------------------+-------------------------------------------------
  Reporter:  hinder       |       Owner:     
      Type:  enhancement  |      Status:  new
  Priority:  minor        |   Milestone:     
 Component:  Cactus       |     Version:     
Resolution:               |    Keywords:     
--------------------------+-------------------------------------------------

Comment (by 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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1042#comment:1>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list