"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).
