[petsc-dev] building PETSc plugins separately

[Barry Smith]

  As Matt noted PETSc has a support for plugins since the 90s but it has always languished. This is because no one used them and there seemed no particular demand for them or use cases where they really helped. Look even Roscoe’s case that allegedly stopped an important project in its path for years doesn’t even have circular dependencies and is trivial to handle if tribits didn’t suck. So yes, true plugins are cool but unless they really bring something new to the table they will languish.

   Barry



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().  Static libraries are the issue.
> 
>>   a) -prefix install was already made and the plugin install
>>   installer does not have write access there
> 
> As in, someone else installed PETSc.  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.
> 
> 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.