[petsc-dev] circular dependencies SLEPc

[Smith, Barry F.]

  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.

  Barry



> On Jun 26, 2019, at 1:15 PM, Patrick Sanan <patrick.sanan at gmail.com> wrote:
> 
> How about a plug-in PC implementation, compiled as its own dynamic library, depending on both SLEPc and PETSc? 

  
> 
> Smith, Barry F. via petsc-dev <petsc-dev at mcs.anl.gov> schrieb am Mi. 26. Juni 2019 um 21:07:
> 
> 
> > On Jun 26, 2019, at 10:55 AM, Jed Brown <jed at jedbrown.org> wrote:
> > 
> > "Smith, Barry F. via petsc-dev" <petsc-dev at mcs.anl.gov> writes:
> > 
> >>> On Jun 26, 2019, at 9:56 AM, Balay, Satish via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> >>> 
> >>> On Wed, 26 Jun 2019, Jakub Kruzik via petsc-dev wrote:
> >>> 
> >>>> Hello,
> >>>> 
> >>>> as I mentioned in PR #1819, I would like to use SLEPc in PETSc.
> >>>> 
> >>>> Currently when PETSc is configured with --download-slepc, it defines
> >>>> PETSC_HAVE_SLEPC and each compilation of PETSc recompiles SLEPc.
> >>> 
> >>> yes - slepc uses petsc, so when petsc is updated - its best to rebuild slepc
> >>> 
> >>> You can ignore PETSC_HAVE_SLEPC flag [its just a build tool thingy]
> >>> PETSc code does not use this flag - and there is no circular
> >>> dependency.
> >>> 
> >>>> The first way to use SLEPc is from an example. That should be easy, all we
> >>>> need is to add -lslepc when compiling an example.
> >>> 
> >>> Its best to use slepc examples as templates - and slepc makefiles [as examples].
> >>> 
> >>> --download-slepc is a convinence feature to install petsc and slepc in
> >>> a single go. It does not change how you would use slepc.
> >>> 
> >>> Satish
> >>> 
> >>> 
> >>>> 
> >>>> The other option is to use SLEPc inside PETSc code. I do not know how to
> >>>> achieve this. One way could be to define PETSC_HAVE_SLEPC after the
> >>>> compilation of SLEPc and again compile PETSc but this time linking with SLEPc.
> >>>> Although, even if it works, it is ugly.
> >> 
> >>   If you make SLEPc calls from PETSc source you should only need the SLEPc header files to compile the PETSc source; not the SLEPc library. So one way to accomplish this would be to do a "partial" install of SLEPc, build PETSc (that uses SLEPc) and then complete the SLEPc install. When --download-slepc is used this would mean during the SLEPc.py script it would copy over the SLEPc include files to the prefix location and after PETSc is built it would build the SLEPc libraries and move them to the prefix location.  The on iffy thing is that SLEPc include files may depend on generated PETSc include files (which are not fully generated until configure is done). Thus instead of having SLEPc.py move the SLEPc include to the prefix location it would need to post-pone that until just at the end of configure (we have other packages to do this). So when you ready to try this out let us know and we can help with the infrastructure. (it will avoid 2 builds of either PETSc or SLEPc).
> > 
> > That is disgusting.
> > 
> > If code in libpetsc.so depends on libslepc.so, then you'd have a circular dependency.
> > 
> > 
> > You can implement and register a PC in SLEPc (it would go in libslepc.so).
> 
>   It makes no sense to have a PC in SLEPc. 
> 
>