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 <[email protected]>
>
> That's what I suggested on Thursday <[email protected]>.
> 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.
