handling PETSc patch version updates (e.g. 3.7.5 to 3.7.6)

[Drew Parsons]

The soname in PETSc libraries is libpetsc.so.3.7 or similar, so in principle the PETSc 3.7 installations should be interchangeable for any patch version (with client programs built against PETSc 3.7.5 being able to run under PETSc 3.7.6, for example).

petsc4py specifies the specific PETSc patch version in 3 places: 1) via RPATH in .../python/dist-packages/petsc4py/lib/PETSc.so 2) via a string ("/usr/lib/petscdir/3.7.5/x86_64-linux-gnu-real/include/petscsys.h") embedded in petsc4py's PETSc.so 3) returned by petsc4py.PETSc.Sys.getVersion() or petsc4py.PETSc.Sys.getVersionInfo()

The patch-specific references appear even where PETSC_DIR is set to a general value e.g. PETSC_DIR=/usr/lib/petscdir/3.7 (symlinked to the latest PETSc 3.7 installation, e.g. 3.7.5 or 3.7.6). I understand the patch versions that petsc4py is handling would have been picked out of /usr/lib/petscdir/3.7/lib/petsc/conf/petscvariables or similar places in the PETSc installation.

Of course we could just rebuild petsc4py to match the latest PETSc patch version after upgrade, but ideally we'd want one installation of petsc4py to work with any compatible PETSc.

The RPATH reference can be removed with chrpath -d (or by not linking with -rpath in conf/baseconf.py), but the other 2 references are hardcoded at build time.

With petsc4py built against PETSc 3.7.5, the petsc4py tests still run fine under PETSc 3.7.6 (after deleting the RPATH). So the hardcoded petscsys.h path might not be a problem in practice. getVersion() is for information only. petsc4py still works if getVersion() is out of sync with the actual PETSc version.

But I think it would be desirable if getVersion() returned the current version that is being used at runtime (or, perhaps, if paths were kept relative to the PETSC_DIR used at build time).

It would simplify packaging (e.g. python-petsc4py in Debian) if petsc4py only needed to be built once for a given PETSc minor version, and not have to depend on the specific patch version.

[Lisandro Dalcin]

@drewparsons As per our private email discussion, once you update your Debian build rules for upcoming PETSc 3.8 and considering my changes in c17fec7615a2b2edd73216238c3d61d866b82c53, I guess this can be closed as fixed. Please confirm.

[Drew Parsons]

The new patch will give the version in use at runtime, so that will be good. I can adapt the Debian packaging to install into a directory for minor version, not patch-specific. I'm happy with your solutions.