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

[Zachary Turner via lldb-commits]

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.  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> wrote:

>
>
> > On May 22, 2018, at 6:57 PM, Zachary Turner <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/cceb582c/attachment.html>