[petsc-users] petsc externalpackage directory

[Satish Balay]

On Tue, 2 Feb 2016, Jed Brown wrote:

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

This has nothing to do with sources in PETSC_ARCH/externalpackages. They are equivalent to tarballs.

[stuff in PETSC_ARCH/include can conflict]

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

Each time configure is invoked with --download-package - it does a
'make clean' or equivalent in each of these packages/build dirs - and
then rebuilds.

Satish