On Fri, 28 Jun 2019, Jed Brown via petsc-dev wrote: > If we configure with --download-pnetcdf (version 1.9.0), then update the > PETSc repository to use a new version (1.11.2), then re-run ./configure > --download-pnetcdf, we get a warning making us look like dolts: > > =============================================================================== > > > Warning: Using version 1.9.0 of package pnetcdf; PETSc is tested with > 1.11 > > Suggest using --download-pnetcdf for a compatible pnetcdf > > > =============================================================================== > > It looks like we have a mechanism for gitcommit versions, but not for > normal numbered versions?
Yes. We have some overloaded functionality here wrt --download-package for tarballs. This is to partly support: --download-package=URL [where URL could be a different version - or have a different dir structure in the tarball]. And then - our desire to avoid re-download the package if its already downloaded. Perhaps this part can be improved by stashing the tarball somehow that corresponds to the URL used.. [but sometimes one can use the same tarball with a different URL] Wrt a git repo, one can overcome this with: --download-package=git://URL --download-package-commit=HASH [but configure does not expect the URL to change after a clone is created - so that part can break] Satish > > NB: There are other changes in updating pnetcdf that will bypass this > issue today, but I wanted to raise it in case someone had a vision for > how the logic should be organized. It's currently spread out, and > any attempt at a fresh download is skipped if there is a matching > download directory: > > if not self.packageDir: self.packageDir = self.downLoad() >
