[petsc-dev] circular dependencies SLEPc

[Jed Brown]

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

>> On Jun 26, 2019, at 1:53 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> "Smith, Barry F." <bsmith at 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

We're using __attribute((constructor)) in libCEED to avoid having a central registration list (like in PCRegisterAll).  It has been working fine.