<div dir="ltr"><div dir="ltr">On Wed, Jun 26, 2019 at 1:48 PM Balay, Satish via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even if SLEPc were merged to PETSc - we would normally avoid circular<br>
dependencies between components - i.e avoid slepc calls from pc/ksp<br>
[this would break --with-single-library=0 build]<br></blockquote><div><br></div><div>Totally agree. However, in a single repo, we could just relocate the code in the tree, preserving all the other development structures.</div><div>Is there a way we can make it look like that (like BuildSystem) without actually merging all the way? Would that make more sense</div><div>for the SLEPc developers?</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Satish<br>
<br>
On Wed, 26 Jun 2019, Fande Kong via petsc-dev wrote:<br>
<br>
> It would be great if SLEPc can be merged into PETSc. Just like what we did<br>
> for TAO. Then we do not have all these issues at all.<br>
> <br>
> Any particular reason we can not merge SLEPc into PETSc?<br>
> <br>
> Fande,<br>
> <br>
> On Wed, Jun 26, 2019 at 11:22 AM Jed Brown via petsc-dev <<br>
> <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
> <br>
> > Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
> ><br>
> > > On Wed, Jun 26, 2019 at 1:05 PM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
> > ><br>
> > >> Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
> > >><br>
> > >> > On Wed, Jun 26, 2019 at 12:45 PM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
> > >> ><br>
> > >> >> Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
> > >> >><br>
> > >> >> >> You can implement and register a PC in SLEPc (it would go in<br>
> > >> >> libslepc.so).<br>
> > >> >> >><br>
> > >> >> ><br>
> > >> >> > I think this is the bad workflow solution. What Barry suggested<br>
> > will<br>
> > >> work<br>
> > >> >> > and be MUCH easier for a developer. Isn't<br>
> > >> >> > the point of our tools to make our lives easier, not to enforce<br>
> > rules<br>
> > >> >> that<br>
> > >> >> > make them harder?<br>
> > >> >><br>
> > >> >> Circular dependencies with a special build process is an enormous<br>
> > >> >> development and distribution tax.<br>
> > >> >><br>
> > >> ><br>
> > >> > The difference in the arguments here is that there are very specific<br>
> > >> > problems with the "right" way,<br>
> > >> > namely that I need to deal with two different repos, two testing<br>
> > systems,<br>
> > >> > release schedules, etc.<br>
> > >> > Whereas the taxes above are currently theoretical.<br>
> > >><br>
> > >> It isn't remotely theoretical.<br>
> > >><br>
> > >> You could propose merging SLEPc into the PETSc repository (similar to<br>
> > >> what we did with TAO a while back) if you think "PETSc" code will<br>
> > >> frequently need to depend on SLEPc, but creating a circular dependency<br>
> > >> between separate packages is worse than having code in Vec that depends<br>
> > >> on DM.<br>
> > >><br>
> > ><br>
> > > I think there will be very frequent dependencies. I would say this is<br>
> > > a very convenient stopgap that is preferable to making anyone work in<br>
> > > both places at once.  That is a very real development nightmare.<br>
> ><br>
> > As a concrete issue unrelated from packaging/distribution (which is very<br>
> > important), what happens when a PETSc interface used by SLEPc changes in<br>
> > a branch?  If the repositories are separate and you have this circular<br>
> > dependency, the PETSc build and tests fail until SLEPc updates to the<br>
> > new interface and that lands in 'master' where PETSc can use it.  But<br>
> > the SLEPc updates can't land until the branch with this new change is<br>
> > merged in PETSc, so you have to do custom testing and synchronize these<br>
> > merges.  Stop-the-world disruption is not okay, full stop.<br>
> ><br>
> > I think it's up to Jose whether closer integration is desirable.<br>
> ><br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>