[petsc-dev] building PETSc plugins separately

[Barry Smith]

    I posted an issue, 53 about doing this with PETSc.   Here is my thinking (to evolve from what we have now but change as little as possible (in some measure))

    Say PETSc is already installed (with shared libraries) but without hypre support

From the perspective of the user:

1) the user downloads the usual PETSc configuration file

2) the user runs the usual ./configure 

    a)  with the additional options —enable-plugins    and somehow indicates the location of the installed PETSc and where the plugins will go

    b) they pass in whatever arguments are needed for an external package, for example —download-hypre or —with-hypre-dir

    c) internally configure uses Matt’s find Petsc thing to make sure the PETSc install is ok, bypasses most of the operations except the external packages and generates appropriate gmake thing

3) the user runs make ; make install which runs make in the appropriate external library directories, builds the libraries and puts them in the appropriate place.

If this all works then eventually we could generate a petsc-plugins.tar.gz that excludes all the rest of the code just to be a bit slimmer. 

The point is to reuse almost everything we already have (and just short-circuit unneeded stuff), rather than creating a new infrastructure for building/compiling plugins. Maintain two sets of builders would be nuts and in the end even building plugins will need so much of the infrastructure it would be crazy to write a separate “smaller” infrastructure. (For example some external package .pys need to test for certain blas routines, certain other machine capabilities, we can already do that so just use what we have.

   Barry




Begin forwarded message:

> From: Jed Brown <jedbrown at mcs.anl.gov>
> 
> That's what I suggested on Thursday <87y54h4ohf.fsf at jedbrown.org>.
> PETSc needs zero source-code modifications to do this, just a simple
> build system change and some mechanism of informing the user how to link
> the libpetsc-ml.a (or libpetsc-trilinos.a if we bundle plugins for
> matrix types, MueLu, and whatever else).
> 
> It is the distribution and informing the user of how to link that I'm
> most concerned with.  Separate distribution means we would need another
> configure.
> 
> * Should that configure trust configure results obtained earlier by
>  PETSc and/or Trilinos build systems?  People will accidentally or
>  intentionally change their environments between configures, so
>  trusting earlier results will create support email.  But while
>  configure takes one minute on a laptop, it takes an hour on a
>  "leadership" machine, so re-running configure hurts usability (human
>  time to install).
> 
> * Will there be an option to automatically download?  (Most PETSc users
>  use --download-ml instead of installing on their own.)
> 
> * Current users can include PETSc makefiles, run a command-line tool, or
>  use FindPETSc.cmake to determine how to link.  If the plugins are
>  distributed separately, where will the user's build system get link
>  information?  That step must be exactly the same with or without
>  plugins and with static or shared libraries.  Users of shared
>  libraries should be able to link only with -lpetsc.