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
rt Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091002/77bddb79/attachment.html>
On Oct 2, 2009, at 9:38 AM, Matthew Knepley wrote:
> On Fri, Oct 2, 2009 at 9:11 AM, Richard Tran Mills 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
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
n
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/e
