I think some packages don't match tarball names with the dir-name. So one stratergy is to stash the tarball name somewhere [inside the extracted dir]
And then - use this info to check for a match - the next time configure is run.. We do make some updates of tarballs without changing the tarball names. These updates wouldn't be caught though.. Satish On Fri, 2 Oct 2009, Barry Smith wrote: > > This is easy enough if we have a way of knowing the package is "out of > date". We could do it based on if the directory name matches the base part of > the tarball file name that is being downloaded. This would work if the > directory name is always the same as the base part of the tarball file name. > Is this true? > > Then simply write a short message to the screen saying deleting old version, > python unlink it and proceed as normal. > > > Barry > > On Oct 2, 2009, at 9:11 AM, Richard Tran Mills 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? > > > > Sincerely, > > Richard >
