"Smith, Barry F." <bsm...@mcs.anl.gov> writes: >> 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
We're using __attribute((constructor)) in libCEED to avoid having a central registration list (like in PCRegisterAll). It has been working fine.
