[petsc-dev] building PETSc plugins separately

[Barry Smith]

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

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   This discussion is two vague about what cases you are considering
>> 
>>   1)  Dynamic or  2) shared libraries
> 
> I don't understand this distinction.  Shared libraries can be opened
> with dlopen().

   Sure

>  Static libraries are the issue.

Yes

> 
>>   a) -prefix install was already made and the plugin install
>>   installer does not have write access there
> 
> As in, someone else installed PETSc.  

  Yes, this is the most important case I think.

> Such as a system administrator on
> a Cray.  Being able to add external packages to such a build would be a
> neat feature, though we probably need to talk to the Cray folks to
> ensure that it works properly (changing petscconf.h behind our backs can
> break things like this).
> 
>>   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.
> 
> If we only do plugins when shared libraries are available, then we just
> need plugin paths.  That could be an environment variable
> PETSC_PLUGIN_PATH containing a list of directories that PetscInitialize
> walks through, loading any shared libraries.  There could even be a
> default global plugin path and a default local (per user) path, so that
> typical users don't have to mess with the environment variable, though
> if we do that, PETSC_ARCH should appear somewhere so that they don't
> collide.

  Yupe

> 
> It's messier for static libraries because the user needs to link them
> explicitly.  If we create a petsc-config program (similar to pkg-config,
> but I think we need to execute our code), it could walk through the
> designated plugin paths to construct a suitable link line that would
> include all the plugins.

   Yupe

   Or if users used our makefile :-)

Barry