Re: [petsc-dev] circular dependencies SLEPc

[Smith, Barry F. via petsc-dev]

> On Jun 26, 2019, at 1:53 PM, Jed Brown <j...@jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
> 
>>  It can be a plug-in whose source sits in the PETSc source tree, even in the 
>> PC directory. It gets built by the PETSc build system after the 
>> build system installs PETSc and SLEPc (in the Spack world it would have its 
>> own Spack file that just depends on PETSc and SLEPc). Pretty easy to setup 
>> (and yes less hacky than my previous suggestion). 
>> 
>>   The only thing missing is the PCRegister(newmethod) inside the PETSc 
>> library so -pc_type newmethod is truly transparent but actually even that is 
>> workable with dynamic libraries, each PETSc dynamic library has a function 
>> that is called by PETSc when PETSc loads the library, this routine could 
>> call the registration function. One can provide, for example in an 
>> environmental variable a list of dynamic library plug-ins that PETSc loads, 
>> but I now realized
>> and even more transparent way, in the PETSc install library directory we 
>> have a subdirectory (called say petsc-plugins), PETSc sys would 
>> automatically load these libraries at run time and thus transparently 
>> register the new PC.  Almost close enough to satisfy Matt without the 
>> hackyness of my first suggestion that Jed hated. Drawback, only with dynamic 
>> libraries for the plug-ins.
> 
> With static libraries, the user would just need to link the libpetsc-plugin.a.
> 
> Actual registration can be done using __attribute((constructor)) (or a
> C++ static constructor, but I think the attribute is widely supported).

  Good idea. If the combination of the two is widely supported then we don't 
need to even worry about the dynamic library case; which will be a relieve