[petsc-dev] circular dependencies SLEPc

Matthew Knepley knepley at gmail.com
Wed Jun 26 12:13:52 CDT 2019


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.

   Matt

-- 
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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190626/a1599ff8/attachment.html>


More information about the petsc-dev mailing list