[petsc-dev] building PETSc plugins separately

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>     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.

So I believe plugin defines need not be in the header (petscconf.h).  If
we generate them in a separate file, the rest of PETSc would not be
recompiled after an update.

To maintain the same linking interface, libpetsc.a would need to be
relinked after activating plugins.  Do you consider this to be
acceptable?

$PETSC_ARCH/conf/reconfigure* --download-{ml,hypre,sundials} --trust-cached-configure

That would trust the old configure tests and just add the new
components.  petscconf.h would not be updated because PETSC_HAVE_XXX
would not be written there, so make would only compile the new stuff.


The problem with this workflow is that libpetsc.a is no longer a node in
a DAG.  But if the plugins go elsewhere, the user needs to link
differently based on whether the plugin has been activated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131123/724ddf6a/attachment.sig>