Hi Ben,
On 13/10/15 03:13, Ben Roberts wrote:
I have found the problem.
In my easyconfigs for Amber, I have set the variable “onlytcmod” to True. This
was found necessary because otherwise Easybuild sets a bunch of environment
variables, one or more of which interact unhelpfully with Amber’s build process.
The problem is that onlytcmod will also force compilers to remain unset, so
that I then can’t use the CC, CXX, etc. variables set by Easybuild.
And the question then changes, so that it is now: is there a way to cherry-pick
variables so that a list of known “safe” variables can be set by Easybuild,
with the rest set “manually” in the Easyblock? If so, how can I get a list of
variables that are set by the Easyblock? Disable onlytcmod and then look at the
logs?
No, but you can do the reverse (as you already know, I think), using the
'unwanted_env_vars' easyconfig parameter, that takes a list of names of
environment variables that should be unset.
I think this is a better approach too: see what makes the build trip,
and unset that. $LIBS is a common one.
We currently don't have good documentation on all the environment being
defined, but we're working on it.
The new --extended-dry-run feature that is in the works (and should be
ready by the next release v2.4.0) will improve on that a lot.
An overview of the build environment as defined by EasyBuild is
available in the example output in the WIP documentation for
--extended-dry-run, see
http://boegel-eb.readthedocs.org/en/extended_dry_run/Extended_dry_run_examples.html#extended-dry-run-examples-wrf361-intel2015a
.
regards,
Kenneth
Cheers,
Ben
On 13/10/2015, at 11:28 AM, Ben Roberts <[email protected]> wrote:
I’m trying it in the Amber 12 toolchain, in the configure step (just before the
configure command itself is called). The toolchain is ictce-5.4.0.
Curiously, I’ve just tried passing the variables in explicitly, setting
preconfigopts:
self.cfg.update('preconfigopts', "CC={0} CXX={1} F77={2} F90={3}
{4}".format(os.getenv('CC'), os.getenv('CXX'), os.getenv('F77'), os.getenv('F90'),
self.cfg['preconfigopts']))
and what comes up in the output of the configure script (a file called
config.h) is CC=None and FC=None.
Cheers,
Ben
On 13/10/2015, at 11:25 AM, Kenneth Hoste <[email protected]> wrote:
Hi Ben,
On 13/10/15 00:07, Ben Roberts wrote:
Hi list,
Recently, it was suggested to me (by wpoely86) that I could patch custom
configure scripts so that they use the CC, CXX, F77 and F90 environment
variables, in place of naming the compiler executables explicitly.
I have done this, but for some reason the configure script doesn’t pick these
up, so that I get empty strings being used. This is obviously a problem as it
breaks the installation.
I see that the configure script is called by means of run_cmd. If I call “env |
sort” with run_cmd, the environment variables CC and F90 (for instance) are
also unavailable. Perhaps this is because run_cmd spawns a new shell that just
reads in from the resource files (.bashrc, etc.). I could presumably force the
environment variables in with read_environment, but that seems a bit ugly and
ad hoc. Is there a better way to do this?
Yes, all commands run via run_cmd are run in a subshell, but that doesn't mean
the environment is reset at all...
It does have some consequences, but the other way around: changes in the
environment in the subshell are not exposed to the process running the command.
When are you running 'env | sort' with run_cmd exactly (which step, in
particular), and which toolchain are you using?
The only case where $CC and co would not be defined by EB is when a 'dummy'
toolchain is used.
regards,
Kenneth
