[Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target
Jim Ingham via lldb-commits
lldb-commits at lists.llvm.org
Tue May 22 14:03:06 PDT 2018
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.
> On May 22, 2018, at 11:57 AM, Zachary Turner <zturner at 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 <aprantl at 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 <zturner at 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 at 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:
>> rL LLVM
>> lldb-commits mailing list
>> lldb-commits at lists.llvm.org
More information about the lldb-commits