On Oct 2, 2009, at 9:38 AM, Matthew Knepley wrote:
On Fri, Oct 2, 2009 at 9:11 AM, Richard Tran Mills rmills at
climate.ornl.gov
wrote:
BuildSystem Folks (Matt, mainly),
This is not really a problem for me since I know about this behavior
already, but I note that it can cause significant confusion when
configure.py has been asked to download a package and a very out of
date version of that package already exists in $PETSC_DIR/
externalpackages. In this case, configure.py doesn't do anything
since the package is already there, but in some cases the interfaces
have changed and that package isn't actually usable. For instance,
if hypre-2.0.0 is present, it won't work with the current petsc-dev,
but the configure proceeds anyway, even though things won't work
unless hypre-2.4.0b is downloaded. In such a case, deleting the
hypre-2.0.0 directory and re-running configure.py will fix the
problem, but it seems like this isn't very user-friendly and I know
that it does cause some confusion.
I am no BuildSystem hacker (I think I've committed a change maybed
once, in 2005?). Can someone tell me if it is reasonable to make
configure.py download the new package if the old one is too out of
date?
This is the versioning problem, which has no good resolution. The
way I understand things, with a given version of PETSc, this problem
cannot arise, UNLESS it is petsc-dev. I am willing to live with this
problem in petsc-dev, rather than introduce some versioning scheme
which is just as broken as the current scheme.
Yes it should only happen in petsc-dev.
See my proposed solution; it is just a few lines of code and
will eliminate most problems I believe without introducing a
complicated overhead. What do you think?
Even if someone changes the tarball's name this will also cause and
extra download which is harmless enough.
Barry
Matt
Sincerely,
Richard
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener
