[Lldb-commits] [PATCH] D34400: Move Connection from Core to Host

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Tue Jun 20 09:30:40 PDT 2017

On 20 June 2017 at 16:47, Zachary Turner <zturner at google.com> wrote:
> I do think at some point we will need to break up Host, but whether the best
> way is to move stuff into Utility or to somewhere else is an open question.
> Host also depends on Target, Symbol, process plugins, and various other
> things. So we will need a way to group together all the stuff in Host that
> has no other dependencies. This could then remove the dependency from X ->
> Host for many values of X.
The process plugin dependency has already been removed. The current
list I see is:
Core, Interpreter, Symbol, Target, ScriptInterpreterPython. It's a
fair number of things but it's not too many.

> I agree that Core is bigger, but unfortunately with deps it's kind of all or
> nothing. You don't see any benefit from removing 99 if there's still 1 more.
Yes, that's true. My intention is to slowly go through them and remove
all 100 of them. I'm not saying it will be done quickly, and I don't
even have much time to dedicate to that, but I can eventually get

> If you don't want to do it now that's fine as it does indeed require moving
> many other things, but moving it to Host seems like a lateral move at best -
> nothing gained nothing lost. What about moving the base class to Utility? At
> least then you wouldn't need to link Host to use Connection, which could
> encourage a factory-like pattern
Yes, it does not bring us anything right now. But after I remove all
of the Host->Core dependencies, I can remove the direct edge from the
dependency graph, which I think *is* something. We will still have an
indirect edge through one of the other modules, but it decreases the
scope of the problem (density of the graph).

As for the "moving the base class to Utility" idea, I had considered
that already. Eventually, I decided I prefer keeping it in Host, close
to the other classes, but it's a weak preference. I'd like to hear
what others think about this.


More information about the lldb-commits mailing list