<div dir="ltr">After <a href="https://reviews.llvm.org/D29964">https://reviews.llvm.org/D29964</a>, we finally have a starting point at which we can begin unravelling the cross-project cyclic dependencies in LLDB.  lldb/Utility now is very similar in spirit to llvm/Support.  <div><br></div><div>But llvmSupport goes one step further and includes what lldb would normally put under Host.  I think this makes some sense.  Practically all parts of a codebase have need of a single OS abstraction layer.  So, I think that a lot of the functionality currently in lldbHost is in fact needed by the rest of LLDB.</div><div><br></div><div>So, I wonder if it makes sense to follow the path that LLVM has taken, and start moving some of this code from Host down to Utility.  Doing so would allow us to break one of the biggest links in the dependency cycle in the entire codebase, which is that Host depends on everything, and everything depends on Host.  </div><div><br></div><div>Of course, it can't just be a straight move.  Some things in Host interact with Target, with CommandInterpreter, and with many other things.  And stuff going into Utility can't take a dependency.</div><div><br></div><div>So there will be some splitting, some moving, some refactoring, etc.  But to me tackling Host seems like the logical next step, in large part because Host is where FileSpec is, and it's going to be hard to break any dependencies without first addressing FileSpec.</div><div><br></div><div>The way LLVM handles cross-platform differences in Support is that you include a single header and it does conditional includes into a platform specific subdirectory for the parts that differ.</div><div><br></div><div>I'm thinking to follow the same pattern here in lldb/Utility, and begin looking for ways to get pieces of Host down into Utility this way, until ultimately I can get FileSpec down there.  </div><div><br></div><div>Thoughts?</div></div>