SystemInitializerFull.cpp, in the function SystemInitializerFull::Initialize().
On Wed, May 23, 2018 at 9:44 AM Adrian Prantl <apra...@apple.com> wrote: > > > On May 23, 2018, at 8:51 AM, Zachary Turner <ztur...@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 <apra...@apple.com> wrote: > >> >> >> > On May 22, 2018, at 6:57 PM, Zachary Turner <ztur...@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 >> >> >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
