On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown wrote:
> Barry Smith writes:
>
> >> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
> >>
> >> In this case, it might be more reliable to compare "cc --version".
> >
> > Presumably this is trivial with the gnumake stuff?
>
> It's easy to run it and com
Barry Smith writes:
> Plenty of things are desirable, some are even achievable, but even fewer
> are worth doing.
Well, this sort of checking is what we're talking about because it costs
a lot of human time (both users and developers/support). I proposed an
organization that would allow arbi
Plenty of things are desirable, some are even achievable, but even fewer are
worth doing.
> On Dec 24, 2014, at 3:48 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>>>
>>> In this case, it might be more reliable to compare "cc --version"
Barry Smith writes:
>> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>>
>> In this case, it might be more reliable to compare "cc --version".
>
> Presumably this is trivial with the gnumake stuff?
It's easy to run it and compare before proceeding with the build.
> And the mythical petsc
> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>
>>
>
>
> In this case, it might be more reliable to compare "cc --version".
Presumably this is trivial with the gnumake stuff?
And the mythical petsc-config could do any number of sanity checks each time
it is run.
Barry
> Module
Satish Balay writes:
> Or just have the data in bin/petsc-config? [since this is likely to be
> a different file for each petsc variant thats installed?]
Sure, accessible with something like
petsc-config --raw configure.log
signature.asc
Description: PGP signature
Barry Smith writes:
> Now change the compiler to something else from Cray and run again.
Starting with PrgEnv-gnu:
jedbrow@edison01:~> env | grep MODULE > PrgEnv-gnu.txt
jedbrow@edison01:~> module swap PrgEnv-{gnu,cray}
jedbrow@edison01:~> env | grep MODULE > PrgEnv-cray.txt
jedbrow@e
Jose E. Roman writes:
> El 23/12/2014, a las 20:38, Sean Farley escribió:
>
>> 4) Better coordination with dependent packages
>>
>> This item is hard to implement because it's out of the PETSc team's
>> control. For example, packages like SLEPc depend on PETSc but don't have
>> as good of a buil
Now change the compiler to something else from Cray and run again.
> On Dec 24, 2014, at 12:56 AM, Satish Balay wrote:
>
> wrt cray modules - I see the following env variables set [with a 'MODULE' in
> the env variable name]
>
> Satish
>
> ---
> balay@hopper01:~> env |grep MODULE
> MOD
El 23/12/2014, a las 20:38, Sean Farley escribió:
> 4) Better coordination with dependent packages
>
> This item is hard to implement because it's out of the PETSc team's
> control. For example, packages like SLEPc depend on PETSc but don't have
> as good of a build system. SLEPc can't be built
On Tue, 23 Dec 2014, Barry Smith wrote:
>
> > On Dec 23, 2014, at 7:08 PM, Jed Brown wrote:
> >
> > Barry Smith writes:
> >> Sure, but they have to go into a "legal" location. Where would that
> >> legal location be? We'd start by putting the data as is in the legal
> >> location, then add
On Tue, 23 Dec 2014, Jed Brown wrote:
> Barry Smith writes:
> > Sure, but they have to go into a "legal" location. Where would that
> > legal location be? We'd start by putting the data as is in the legal
> > location, then add a bin/petsc-config to process that data (crudely)
> > then re
12 matches
Mail list logo
