[petsc-dev] circular dependencies SLEPc

[Fande Kong]

It would be great if SLEPc can be merged into PETSc. Just like what we did
for TAO. Then we do not have all these issues at all.

Any particular reason we can not merge SLEPc into PETSc?

Fande,

On Wed, Jun 26, 2019 at 11:22 AM Jed Brown via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > On Wed, Jun 26, 2019 at 1:05 PM Jed Brown <jed at jedbrown.org> wrote:
> >
> >> Matthew Knepley <knepley at gmail.com> writes:
> >>
> >> > On Wed, Jun 26, 2019 at 12:45 PM Jed Brown <jed at jedbrown.org> wrote:
> >> >
> >> >> Matthew Knepley <knepley at gmail.com> writes:
> >> >>
> >> >> >> 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?
> >> >>
> >> >> Circular dependencies with a special build process is an enormous
> >> >> development and distribution tax.
> >> >>
> >> >
> >> > The difference in the arguments here is that there are very specific
> >> > problems with the "right" way,
> >> > namely that I need to deal with two different repos, two testing
> systems,
> >> > release schedules, etc.
> >> > Whereas the taxes above are currently theoretical.
> >>
> >> It isn't remotely theoretical.
> >>
> >> You could propose merging SLEPc into the PETSc repository (similar to
> >> what we did with TAO a while back) if you think "PETSc" code will
> >> frequently need to depend on SLEPc, but creating a circular dependency
> >> between separate packages is worse than having code in Vec that depends
> >> on DM.
> >>
> >
> > I think there will be very frequent dependencies. I would say this is
> > a very convenient stopgap that is preferable to making anyone work in
> > both places at once.  That is a very real development nightmare.
>
> As a concrete issue unrelated from packaging/distribution (which is very
> important), what happens when a PETSc interface used by SLEPc changes in
> a branch?  If the repositories are separate and you have this circular
> dependency, the PETSc build and tests fail until SLEPc updates to the
> new interface and that lands in 'master' where PETSc can use it.  But
> the SLEPc updates can't land until the branch with this new change is
> merged in PETSc, so you have to do custom testing and synchronize these
> merges.  Stop-the-world disruption is not okay, full stop.
>
> I think it's up to Jose whether closer integration is desirable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190626/093f77df/attachment-0001.html>