On 20 June 2017 at 16:47, Zachary Turner <ztur...@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 there. > > 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. ? _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
