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
