Where clang stores modules by default on the host system seems like a Host function. It isn't in practice because that gets delegated to clang to do the host specific calculation, but in theory that seems where the functionality properly belongs. It's a little odd to have ModuleList depend on Host, but much less strained than to have it depend on clang.
Jim > On May 22, 2018, at 11:57 AM, Zachary Turner <ztur...@google.com> wrote: > > We've been going to a lot of effort recently to separate out dependencies and > properly layer libraries. Even if we deemed this to be an acceptable > location to #include something from clang/Driver, the CMake does not actually > reference clangDriver in its link list. So the only reason this is working, > AFAICT, is because most of the final executables ultimately link in all of > clang. But that in and of itself is something we are trying to move away > from. For theoretical reasons (i.e. it doesn't make sense from a layering > standpoint) as well as more practical reasons -- we should be able to use > LLDB as a library, and we should be able to link against pieces of it without > requiring all of clang (or without requiring all of X where X is anything > unrelated to the logical component we want to use). > > An LLDB module is, conceptually, an abstract concept that is independent of > clang. > > One way to resolve it, perhaps, would be to add a function > > static void setDefaultModuleCachePath(const Twine &Path); > > Then, during startup where we are in the LLDB driver and have linked against > everything including clang, call > setDefaultModuleCachePath(clang::driver::Driver::getDefaultModuleCachePath()); > > If the ModuleListProperties class were somewhere else, perhaps this would be > less of a problem. But we can't have a dependency from Core to clang (and > especially not a newly introduced one. There is already one there to > clang/AST that we are trying to remove). > > On Tue, May 22, 2018 at 11:32 AM Adrian Prantl <apra...@apple.com> wrote: > Can you help me understand why this dependency poses a problem? It's not > clear to me how to resolve this otherwise. The point of the patch is to ask > the clang driver for the clang module cache path. If the problem is that we > otherwise don't use the driver and now pull it in, would moving the Clang API > into a different clang library work? Which one? > > -- adrian > >> On May 22, 2018, at 11:28 AM, Zachary Turner <ztur...@google.com> wrote: >> >> This change has introduced a dependency from Core -> clang Driver (due to >> #include "clang/Driver/Driver.h" in ModuleList.cpp). Can you please try to >> find a way to remove this dependency? >> >> On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits >> <lldb-commits@lists.llvm.org> wrote: >> This revision was not accepted when it landed; it landed in state "Needs >> Review". >> This revision was automatically updated to reflect the committed changes. >> Closed by commit rL326628: Make the clang module cache setting available >> without a target (authored by adrian, committed by ). >> Herald added a subscriber: llvm-commits. >> >> Changed prior to commit: >> https://reviews.llvm.org/D43984?vs=136803&id=136858#toc >> >> Repository: >> rL LLVM >> >> https://reviews.llvm.org/D43984 >> >> Files: >> lldb/trunk/include/lldb/Core/ModuleList.h >> lldb/trunk/include/lldb/Target/Target.h >> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/Makefile >> >> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/TestClangModulesCache.py >> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/f.h >> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/main.m >> >> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/module.modulemap >> lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py >> lldb/trunk/source/Core/Debugger.cpp >> lldb/trunk/source/Core/ModuleList.cpp >> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp >> lldb/trunk/source/Target/Target.cpp >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
