[petsc-dev] circular dependencies SLEPc

[Matthew Knepley]

On Wed, Jun 26, 2019 at 11:55 AM Jed Brown via petsc-dev <
petsc-dev at mcs.anl.gov> 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).
>

I think this is the bad workflow solution. What Barry suggested will work
and be MUCH easier for a developer. Isn't
the point of our tools to make our lives easier, not to enforce rules that
make them harder?

   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/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190626/f0b7d308/attachment-0001.html>