- removed comment
Cactus should not interpret environment variables as configuration options
Currently, if you have the variable HDF5_DIR set in your shell startup file, Cactus will interpret this as a configuration option and will override whatever is set in your optionlist.
This behaviour occurs because the "make" utility allows you to specify options on the command line which are then converted into environment variables. This is a method for overriding options on the command line.
However, the fact that variables from the user's environment are also overriding the optionlist is very undesirable. It would be good if this could be fixed somehow.
This ticket is in response to #100.
Keyword:
Comments (6)
-
-
- removed comment
Replacing the Makefile is not a bad idea, but I am not so sure using python would be the best option. Given how many problems we see with simfactory and different versions of python being installed (or not) one various systems, one would have to be very careful and test a lot. The logic isn't all that complicated, and the rest of the build system is in perl anyway - IHMO it would make most sense to have the global "Makefile" in perl as well.
-
Rewriting the top level Makefile will not actually prevent Cactus from interpreting (and giving precedence to) ENV variables over what is in option lists. That behaviour is explicitly coded in the
ProcessConfiguration
subroutine inib/sbin/ProcessConfiguration.pl
(and more specifically inAmalgamateOptions
inCSTUtils.pl
).It is related to make indeed passes variables specified on its command line as ENV variables to its children, ie:
make FOO=bar
makes a variable
FOO
available to sub-shells. In particular he ExternalLibaries' use ofconfigure.sh
scripts relies then on (a subset those in@allowed_options
inCST
andProcessConfiguration.pl
) of those being passed as ENV variables which is whereENV{HDF5_DIR}
messing upHDF5_DIR
in an option list actually comes from.If one wants to use only command line options instead of all ENV variables as a source for those
@allowed_options
then one can parseMAKEFLAGS
the way thatlib/make/setup_configuration.pl
does:# parse make command line options FOO=BAR # Set variables from makefile command line first my %MAKEFLAGS; my $commandline = $ENV{"MAKEFLAGS"}; $commandline =~ s/^.*? -- //; while ($commandline =~ /^(.*)\s*\b(\w+)\s*=\s*(.*?)\s*$/) { $MAKEFLAG{$2} = $3; $commandline=$1; }
and use
MAKEFLAGS
instead ofENV
. Before calling any sub-shell inCST
one then should remove all@allowed_options
not inMAKEFLAGS
fromENV.
The ExternalLibraries'
build.sh
scripts (and the Makefile) getsHDF5_INSTALL_DIR
and similar actually frombindings/Configuration/Capabilities/make.HDF5.defn
where a make variableHDF5_INSTALL_DIR
is set (based onconfigure.sh
's output) which make will prefer over anyHDF5_INSTALL_DIR
in ENV.This may fix the issue, though its a bit fragile since make will still use ENV variables for variables not otherwise defined (or eg stored in
config-data/make.config.defn
).Branch
rhaas/envopts
implements what is described above. -
Branch https://bitbucket.org/cactuscode/cactus/branch/rhaas/envopts implements the code fragment shown above.
-
- edited description
- changed status to open
-
Pull request is here:
https://bitbucket.org/cactuscode/cactus/pull-requests/110/cactus-do-not-use-env-vars-for-config
Note that this changes documented behaviour and I myself would not actually be in favor of doing so (even though am providing means)
- Log in to comment
One good way around this would be to rewrite the top-level Cactus makefile in Python. This top-level makefile does not use any real make facilities; it only parses the command and then calls the corresponding "real" makefile in the lib/make directory.
Rewriting this makefile should be straightforward. I began to do this some time ago; I attach the current state of my efforts.