zturner added a comment. In D58654#1410817 <https://reviews.llvm.org/D58654#1410817>, @JDevlieghere wrote:
> I'm not a fan of introducing another library for this. Without a clear > timeline of "fixing" Host it's basically as temporary as anything else in > software development. I also think it's confusing (e,g, new files should go > where?). If you really want a clean slate we should move everything in System > that doesn't depend on anything other than Utility until Host is empty, but > I'm sure everyone agrees that unrealistic and not worth the churn. > > For the record I also very much support a Host library instead of having > everything in Utility. That being said, I could see the config file being > special enough (in that everything depends on it) to be the exception. > > It seems like we could drop the dependencies on Core and Symbol by moving > Symbols somewhere else. How much work would there be left after Pavel's patch? Moving Symbols somewhere else isn't exactly easy though. There's a lot of interdependencies that are slightly different on every Host platform, so it creates a lot of breakage doing things this way. FWIW, I actually wouldn't mind moving everything out of Host into System until Host is basically empty. My next step after this patch was going to be to move MainLoop followed by Socket into System (those are my actual goals anyway). In some ways, approaching the dependency problem from both directions this way is more effective than approaching it from only one side, as this way eventually Host becomes so small that you can just take whatever is left over and have it be subsumed by some other target (probably Core or Symbols). All of that said, I'm not as sold that having a separate library just for Host is even terribly useful. I'll go along with it if that's what everyone wants, but at the end of the day, this library (whether it be called Host, or System, or something else) will almost certainly depend on Utility, and Utility will almost certainly depend on it (for the same reason that Utility currently depends on llvm/Support). This is why in LLVM/Support there are both non-Host specific things, such as `StringExtras.h`, and host specific things, such as `FileSystem.h`, `Thread.h`, etc. I don't think that's actually so bad in practice. So my vote is honestly still to just put this in Utility for consistency with LLVM, but I can agree with `System` or something as part of a transition if it gets us closer to being able to use these utility classes without a dependency on the whole debugger. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58654/new/ https://reviews.llvm.org/D58654 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
