[petsc-dev] configure using stale packages

[Smith, Barry F.]

   If we stash the --download-xxx=yyy   yyy value and the state of the xxx.py then we can  know that the package may be need to be re-downloaded, re-configured, rebuilt, reinstalled. Essentially get the dependencies of package xxx on itself right. There is also the dependency of package xxx on packager www (for example hdf5 changes thus pnetcdf needs to be rebuilt. Finally there is the dependency of xxx on other stuff that may change in config (for example package.py) 

My branch handles all these dependencies (at the cost of rebuilding more than what may need to be rebuilt) but it is a different model then how we have traditionally used --download-xxx. It is not clear to me if we should just discard the old model for a new one, support them both or something else. It seems inefficient to support both models forever, maybe a smarter hybrid of the two is desirable. I need to develop some experience with my new model to see how it can be improved, extended or if it is complete trash. I am not sure trying to "patch up" the old model is the best approach; though maybe it is.

  Barry


> On Jun 28, 2019, at 10:41 AM, Jed Brown via petsc-dev <petsc-dev at mcs.anl.gov> 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?
> 
> 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()