[Lldb-commits] [PATCH] D47235: Move ModuleList's dependency on clangDriver into Host

[Adrian Prantl via lldb-commits]

> On May 23, 2018, at 8:51 AM, Zachary Turner <zturner at google.com> wrote:
> 
> There's not really a diagram, because we don't have an exact vision of what the final layering is going to look like (some things will need to be split up, entirely new targets will need to be introduced, etc).  Mostly it's just built from experience based on what the primary logical function of a target is, and then asking whether or not someone who wishes to use that functionality should be required to link in all of that target's current dependencies.  And hoping that a layering emerges from this process, at which point we can then make a diagram as well as enforce it through CMake / LLVMBuild / etc.
> 
> Core is the fundamental target that contains the basic data structures representing a generic debugger.  A generic debugger shouldn't need to depend on clang.  Someone should be able to (in theory) link against Core (and perhaps a few other targets) and build a Java debugger.  Or a debugger for an embedded platform.  So a dependency on clang doesn't belong there.
> 
> LLDB is a specific debugger which is built on top of Core and other libraries, and so that is why I think it makes sense to expose a static function in Module which allows you to set the clang modules path, and then we do that during LLDB initialization.

Could you point me at a specific source file? It's not obvious to me what "LLDB initialization" means to you.

-- adrian

>   For the record, that still isn't correct from a purity standpoint, because there is a method in Core which claims to have something to do with clang modules.  But at least it's relatively benign.
> 
> In any case, what do you think about that approach?  
> 
> On Wed, May 23, 2018 at 8:42 AM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
> 
> > On May 22, 2018, at 6:57 PM, Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote:
> > 
> > Yea I don’t think this addresses the problem. We should be able to link against parts of lldb without a dependency on clang. Since this is about configuring something related to clang, it seems like it should be isolated to some part of lldb that interfaces with clang 
> 
> And this is the point where I need some help :-)
> The intended layering of LLDB is not at all clear to me. Which LLDB libraries are allowed to link against clang? Do we have a diagram somewhere?
> 
> -- adrian
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180523/0adf4aa6/attachment-0001.html>