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? 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 >
