On Wed, Jun 26, 2019 at 1:48 PM Balay, Satish via petsc-dev < [email protected]> wrote:
> Even if SLEPc were merged to PETSc - we would normally avoid circular > dependencies between components - i.e avoid slepc calls from pc/ksp > [this would break --with-single-library=0 build] > Totally agree. However, in a single repo, we could just relocate the code in the tree, preserving all the other development structures. Is there a way we can make it look like that (like BuildSystem) without actually merging all the way? Would that make more sense for the SLEPc developers? Matt > Satish > > On Wed, 26 Jun 2019, Fande Kong via petsc-dev 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. > > > > 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 < > > [email protected]> wrote: > > > > > Matthew Knepley <[email protected]> writes: > > > > > > > On Wed, Jun 26, 2019 at 1:05 PM Jed Brown <[email protected]> wrote: > > > > > > > >> Matthew Knepley <[email protected]> writes: > > > >> > > > >> > On Wed, Jun 26, 2019 at 12:45 PM Jed Brown <[email protected]> > wrote: > > > >> > > > > >> >> Matthew Knepley <[email protected]> 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. > > > > > > > -- 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/>
