On Fri, 28 Jun 2019, Jed Brown wrote: > "Balay, Satish" <[email protected]> writes: > > > 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]. > > Right, I understand being permissive in that setting, but if someone is > asking to use the package version defined in packages/foo.py, we should > strive for configure to produce the same result as if we had deleted > PETSC_ARCH and reconfigured from scratch with the same options. > > > 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] > > If we trust our former selves, perhaps we can record self.version at the > time of a download and clean/re-download any time we're being asked to > download a different version (e.g., because packages/foo.py has changed). > > > 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] > > Yes, I had to manually fix this in about a dozen PETSC_ARCHes after the > Hypre repository moved.
Barry's new feature of creating a PETSC_ARCH-hash can presumably avoid these problems. [it might build more PETSC_ARCHes than necessary - but can perhaps avoid such issues. Satish
