[petsc-dev] circular dependencies SLEPc

[Smith, Barry F.]

> On Jul 8, 2019, at 9:53 PM, Jakub Kruzik via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> 
> Just to clarify, the suggested solution is a plug-in sitting anywhere in the PETSc source tree with postponed compilation and using __attribute__((constructor)) to register (as in libCEED) for static libraries?

  Yes, this is my understanding. Good luck.

   Barry

> 
> I could try to do that for the computation of eigenvector-based deflation space for PCDeflation next week.
> 
> Jakub
> 
> On 7/8/19 5:49 PM, Smith, Barry F. via petsc-dev wrote:
>>    Sorry for the confusion surrounding this issue. Your code needs to go in its own standalone library that links against both PETSc and SLEPc. You can just the mechanism Jed suggested to have your library call PCRegister() when it is utilized (see previous emails/discussion). You could perhaps look at how the ctetgen package utilizes the PETSc compile system and copy that for your makefile and SLEPc, of course.
>> 
>>     Once you have the "framework" that does this you could make a PR labeled something like WIP and ask for help in getting the details right.
>> 
>>    Barry
>> 
>> 
>>> On Jul 8, 2019, at 9:58 AM, Pierre Jolivet via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
>>> 
>>> Hello,
>>> I’m not sure what’s the status about this issue.
>>> I’m trying to register a PC that is using EPSSolve during PCSetUp, but it’s falling because of undefined references to EPSSomething when linking libpetsc.so
>>> How could I fix this, appart from removing my PC from PETSc and compiling this as a separate library (the idea would be to merge my PC in PETSc, so that would be rather counterproductive in the end)?
>>> 
>>> Thanks,
>>> Pierre
>>> 
>>>> On 27 Jun 2019, at 1:04 AM, Matthew Knepley via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
>>>> 
>>>> On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <jed at jedbrown.org> wrote:
>>>> Matthew Knepley <knepley at gmail.com> writes:
>>>> 
>>>>> On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev <
>>>>> petsc-dev at mcs.anl.gov> wrote:
>>>>> 
>>>>>> "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 is still a PC, it may as part of its computation solve an
>>>>>> eigenvalue problem but its use is as a PC, hence does not belong in SLEPc.
>>>>>>>> Fine; it does not belong in src/ksp/pc/.
>>>>>>>   Why not? From the code mangement point of view that is the perfect
>>>>>> place for it. It just depends on an external package in the same way that
>>>>>> PCHYPRE depends on an external library. Having it off in some other
>>>>>> directory src/plugins would serve no purpose. Of course making sure it
>>>>>> doesn't get compiled into -lpetsc may require a tweak to the make
>>>>>> infrastructure. Make could, for example, skip plugin subdirectories for
>>>>>> example.
>>>>>> 
>>>>>> I think it's confusing to have code that is part of libpetsc.so
>>>>>> alongside code that is not (e.g., won't be accessible to users unless
>>>>>> they also build SLEPc and link the plugin).
>>>>>> 
>>>>>>>   BTW: Matt's perverse use of SNES from DMPLEx could also be fixed to
>>>>>>>   work this way instead of the disgusting PetscObject casting used to
>>>>>>>   cancel the SNES object.
>>>>>> That code could be part of libpetscsnes.so.
>>>>>> 
>>>>> What? I thought I moved everything to SNES a long time ago.
>>>> I thought there was a place where SNES was cast to PetscObject.  There
>>>> is DMAddField, but it's different.
>>>> 
>>>> I can't find it right now. Yeah, AddField is waiting for a true Discretization object.
>>>> I think its spelled G-O-D-O-T.
>>>>  PetscViewerVTKAddField is another example of code that uses PetscObject
>>>> to avoid depending on a higher level type like Vec.
>>>> 
>>>> Viewer is a weird mixin with everything.
>>>> 
>>>>    Matt
>>>> 
>>>> -- 
>>>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>>>> -- Norbert Wiener
>>>> 
>>>> https://www.cse.buffalo.edu/~knepley/
>