JDevlieghere added a comment. In D58654#1410852 <https://reviews.llvm.org/D58654#1410852>, @zturner wrote:
> 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. In D58654#1411084 <https://reviews.llvm.org/D58654#1411084>, @labath wrote: > BTW, what's the reason that you have to have this split now? I understand its > attractiveness from a Zen perspective, but it seems to me that at the end of > the day, it doesn't have that much impact on the new code you're about to > write. It seems to me you could still enforce a clean layering on the new > code by just saying "only ever include stuff from Host or Utility". The fact > that Host transitively pulls in the kitchen sink is unfortunate, but I don't > think it should impact you much. And when we finally clean up Host (which is > something that we'll do eventually, and I hope not too far from now), then > the new code will magically stop depending on the whole world without any > extra effort. > > In D58654#1410852 <https://reviews.llvm.org/D58654#1410852>, @zturner wrote: > > > 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. > > > > > I would actually say that almost nothing should depend on the config file :). > I mean this in the sense that the dependencies should be encapsulated > similarly to how llvm encapsulates all of the external dependencies and the > rest of the code should just use those abstractions. > > However, I too have come to the conclusion that the config file could be an > exception. My reason for that is that for instance our XML abstraction seems > to be misplaced in the Host library. It's kind of true that whether libxml is > present is a feature of the host system, but that's a fairly odd way of > looking at things. Right not I am incubating this idea of creating a > "Formats" library which would house the minidump parser, gdb-remote protocol > support code and similar, XML support seems like it could fit nicely there. > Having the LIBXML_AVAILABLE macro in an easily accessible place would help > make that happen. > > >> 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? > > Yea, symbols is going to be the trickiest part. I've been preparing myself > (both code-wise and mentally) to tackle that by first removing all the other > easy obstacles first. I have a sort of an idea on how to handle that, but I > don't want to go into that here. > > I suppose one way to make progress here would be to move Symbols into some > weird temporary package. Then cleaning up the rest of Host should be easy, > and the temporary package could disappear as soon as Symbols has been dealt > with. It might make my job of cleaning it up easier, as I could just move the > modularized functionality back into Host piece by piece. It shouldn't even > create additional history churn, as that code will need to be rewritten > anyway. I think this inverted approach makes more sense than pulling everything out of host that doesn't depend on anything outside of Utility. Seems like that would create less churn, leave host as the canonical library, and have the same effect. Zachary, how do you feel about that? 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
