zturner added a comment. In D58654#1409974 <https://reviews.llvm.org/D58654#1409974>, @jingham wrote:
> Utility is supposed to be a bunch of stand-alone utility files & headers that > we gather together for convenience's sake. > > Host is where we put all the code that is specific to one or another host, > and any support files that requires. For instance, that's why PlatformLinux > and friends are there, and all the independent platform directories. So it > is odd to move platform specific defines from Host to Utility. > > I don't care much about the name, but having this in Utility when it is > setting Host defines and we have a place clearly set out for host support > files doesn't seem right. That is how Host started out, but I think that that distinction both a) hasn't played out the way we hoped for in practice, and b) isn't necessarily the right line to draw anyway. We have quite a few ifdefs scattered around the codebase for different platforms that are not in Host in places where we couldn't easily (or cleanly) make the code fit into that separation model. On the flip side, lots of stuff has crept into Host that isn't really host-specific, which is why the dependencies are so tangled up. I think following the LLVM/Support model makes sense. It's "Utility", plus what we would normally think of as "Host". This is a lot cleaner than it sounds, and all of the ifdefs and platform specific defines end up only in private implementation files, with none exposed through headers. To be honest, I don't mind if we call it something other than Host (for example it could be called System or something), but the practical issue with using Host today is that it still has a ways to go before it can be linked against without pulling in the rest of LLDB, and the changes needed to get there are not trivial, so it will take some more continued effort. Regardless, in my mind Utility is exactly what you said, but that definition doesn't actually preclude Host-specific things. In fact, putting Host-specific abstractions there solves a lot of problems. Imagine, for example, someone wanted to create a debugging related tool that was not a full-fledged debugger. They might want to use lots of functionality that is in Utility and Host, but not bring in everything else. That's what Utility is to me. It's a set of abstractions that are useful for creating debugging-related tooling that someone can use for that purpose. I don't necessarily care if it's in Utility or some other newly created library we call something else, but we need some immediate way of using these abstractions without linking against the rest of LLDB so that we're not blocked on finishing the layering split. One option would be to just keep growing Utility with these kinds of classes and abstractions until we decide that it's too big, at which point a separation would probably fall out naturally (FWIW, this is how LLVM/Support and LLVM/ADT evolved into what they are) 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
