[petsc-users] petsc externalpackage directory

[Satish Balay]

On Wed, 3 Feb 2016, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> > My point here is - we haven't have problems with it. [if we had - then you would be doing 'rm -rf PETSC_ARCH' 20 times every day..]
> 
> I don't understand this logic.  We tell users to do this several times
> every day.  We might attribute it to having something "old" (like from a
> different version of PETSc), but we never really know.  I don't consider
> the unpacked, dirty source tree in PETSC_ARCH/externalpackages to be in
> any way equivalent to a tarball.  We could insist on out-of-source
> builds, though not all packages support that.  I just don't think it's a
> good idea to advise people to copy the externalpackages directory
> around.  Download the tarballs and copy them wherever you need them.  Or
> open a proxy (easy with ssh) so you don't have to waste effort on the
> silly firewall.

Can you list the externalpackages [with inplace builds] that currently break with the following?

./configure [or make.inc] && make clean && make [lib] && make install [or cp]
./configure [or make.inc] {with different option} && make clean   && make  [lib] && make install [or cp]

Or do you recall any bugreports where we identified this as the issue?

Note: doing the following with petsc configure does not bypass the above usage internally within petsc configure.

./configure --download-package=foo.tar.gz
./configure --download-package=foo.tar.gz {with different options}

As mentioned before - most of the petsc-maint issues you refere to are
due to 'git pull' causing version conflicts or conflicts in
PETSC_ARCH/include in between the above configure runs with different
options - and not the extracted externalpackage sources.

The current system is not ideal - but to me the above 2 usages are
equivalent.

Sure you can say one should always do:

./configure --download-package=foo.tar.gz
rm -rf PETSC_ARCH
./configure --download-package=foo.tar.gz {with different options}

Or configure should do this automatically. But We've always reused
externalpakcages and avoided redownling for all these years - and
suggest 'rm -rf PETSC_ARCH' only when one sees broken builds when
conflicts come up.

In petsc 'master' - the support for git repos is almost ideal [for any
changes with git pull or switch branch or any such thing] - where a
'rm externalpackages' is never necessary [rm PETSC_ARCH/include might
still be needed - i.e 'git clean -f -d -x' could suffice].

So One way to improve current infrastructure is to have every
externalpackage hosted in a git repo.  Alternative - as you suggest is
to add the extra infrastructure needed for tarballs/checksums and
stash them them as primary source. [somehow have to manage
simultaneous download of the same tarball potentially invoked by
different simultaneous configure runs - so that a common taball cache
can be used by all petsc versions/builds]. Then we can discard the
extracted sources [along with the corresponding build files] - with
each configure run - that might result in a rebuild of the
externalpackage.

Satish