[Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

[Zachary Turner via llvm-commits]

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:
>>   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 at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180522/3df703b0/attachment.html>