[petsc-dev] circular dependencies SLEPc

[Jed Brown]

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.