[petsc-dev] building PETSc plugins separately

[Barry Smith]

   This discussion is two vague about what cases you are considering

   1)  Dynamic or  2) shared libraries

   a)  -prefix install was already made and the plugin install installer does not have write access there b) user has old $PETSC_DIR and write access to install location (either prefix or not)

    Do we plan to support 1 a and b,  2 a and b?    What are the similarities in the four cases and differences that need to be handled.

     I think we can come up with something to handle all cases,….


   Barry

On Nov 23, 2013, at 1:31 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

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