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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091002/77bddb79/attachment.html>