[petsc-users] petsc externalpackage directory

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Tue, 2 Feb 2016, Jed Brown wrote:
>
>> Satish Balay <balay at mcs.anl.gov> writes:
>> 
>> > Well my recommendation was for this use case of "same install on a different machine"
>> 
>> If you're installing to the same location on equivalently-configured
>> machines,
>
> I presumed the copy is to a different machine - perhaps with different file system/organization.

Like different versions of compilers or different library versions?
Then the failure mode I mentioned is possible.

>> And it breaks _constantly_.  It must be like 30% of petsc-maint traffic
>> in the past year; advice being "delete PETSC_ARCH and reconfigure".
>
> All of these breakages are usually due to 2 different cases.
> - [as mentioned before] - due to 'git pull' changing dependencies
> - [without git pull or equivalent] conflict between switching from say
>  --download-mpich to --download-openmpi - in install location
>  [PETSC_ARCH/include] and not sources in PETSC_ARCH/externalpackages
>
> I agree starting from tarballs is the recommended way - but this copy
> [of petsc+externalpackages together] will also work.

I said it was unreliable, not that it would necessarily fail.  I don't
think we can claim this is supported behavior without a way to ensure
clean build directories.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160202/08523eb6/attachment.pgp>