Re: [petsc-dev] circular dependencies SLEPc

[Smith, Barry F. via petsc-dev]

> On Jun 26, 2019, at 12:39 PM, Fande Kong via petsc-dev 
> <petsc-dev@mcs.anl.gov> wrote:
> 
> 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.

  Next week libMesh and the following week Trilinos

  Barry

> 
> 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@mcs.anl.gov> wrote:
> Matthew Knepley <knep...@gmail.com> writes:
> 
> > On Wed, Jun 26, 2019 at 1:05 PM Jed Brown <j...@jedbrown.org> wrote:
> >
> >> Matthew Knepley <knep...@gmail.com> writes:
> >>
> >> > On Wed, Jun 26, 2019 at 12:45 PM Jed Brown <j...@jedbrown.org> wrote:
> >> >
> >> >> Matthew Knepley <knep...@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.