labath added a comment.
In https://reviews.llvm.org/D47801#1123051, @sas wrote:
> Don't we risk creating circular dependencies with this? What happens when a
> tool depends on liblldb? you'll have theTool depend on liblldb and liblldb
> depend on theTool.
The same thought has occurred to me, but I believe this should be fine. No
existing INCLUDE_IN_FRAMEWORK tool links to liblldb, just it's individual
components, which is fine. And this is probably a state that we should maintain
for the future.
What I am thinking about is how to reconcile this with the code in
tools/driver/CMakeLists.txt which tries to do a very similar thing by adding
dependencies from lldb->{lldb-server,debugserver}. Ideally, we shouldn't need
to do this sort of thing twice. And indeed, since lldb driver depends on
liblldb, with this patch the branches we are adding to lldb would already be
present implicitly. The only catch there is we would need to make this
dependency unconditional, but that is probably a good thing anyway, as it makes
the dependency graph more predictable.
So, how about we do this instead:
- rename INCLUDE_IN_FRAMEWORK to something more neutral (USED_BY_LIBLLDB or
whatever)
- make the liblldb -> tool dependency not conditioned by LLDB_BUILD_FRAMEWORK
- remove the lldb->tool dependencies altogether
WDYT?
https://reviews.llvm.org/D47801
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
