[Users] environmental variables in Cactus configuration files
ian.hinder at aei.mpg.de
ian.hinder at aei.mpg.de
Wed Nov 21 15:52:52 CST 2018
> On 21 Nov 2018, at 14:45, Miguel Zilhão <miguel.zilhao.nogueira at tecnico.ulisboa.pt> wrote:
>
> hi all,
>
> i'm compiling ET on a local cluster that uses the module system. on this system, once one does
> "module load <...>", the respective path is added to an environmental variable. for instance, doing
>
> $ module load HDF5
>
> sets the environmental variable $EBROOTHDF5:
>
> $ echo $EBROOTHDF5
> /home/share/easybuild/software/HDF5/1.8.20-GCC-7.3.0-2.30-generic
>
> so i was trying to use these in my configuration file, by adding the lines
>
> HDF5_DIR = $EBROOTHDF5
> HDF5_LIB_DIRS = ${EBROOTHDF5}/lib
> HDF5_INC_DIRS = ${EBROOTHDF5}/include
>
> etc, to it. however, these environmental variables don't seem to be correctly expanded, as i get
> things like the following:
>
> Running configuration script for thorn HDF5:
> Additional requested language support: Fortran
> WARNING in HDF5 configuration:
> None of H5pubconf.h H5pubconf-64.h H5pubconf-32.h found in ${EBROOTHDF5}/lib ${EBROOTHDF5}/include
> Automatic detection of szip/zlib compression not possible
> Finished running configuration script for thorn HDF5.
>
> but if i look into the folder ${EBROOTHDF5}/include, these files are clearly there. the compilation
> later fails because of this.
>
> when i specify the full path explicitly in the config file:
>
> HDF5_INC_DIRS = /home/share/easybuild/software/HDF5/1.8.20-GCC-7.3.0-2.30-generic/include
>
> i get no such warnings, and the code proceeds to compile just fine. is this the expected behaviour?
> shouldn't the environmental variables be correctly expanded? if not, what would be the typical
> procedure to compile the code on systems with such module tools?
Hi Miguel,
No, environment variables are not expanded in that way, because optionlists are not evaluated by a shell. Yes, it would be nice if they were, however :) You can do it in parameter files, but not in optionlists. Usually, in this case, we either set the paths explicitly, resulting in a multitude of almost-identical optionlists, or let the external library automatically detect the location by finding an executable on the path (MPI does this, but I don't know if any others do).
I've never used it, but it looks like simfactory provides a solution. In simsubs.py SubAll, it looks like you can use @ENV(EBROOTHDF5)@. Let us know how you get on with that.
--
Ian Hinder
https://ianhinder.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20181121/d11c3caa/attachment.html
More information about the Users
mailing list