teemperor added a comment.
@aprantl It's good for build times and more importantly it's consistent with
the way Clang/LLVM are naming/organizing their modules. But I actually don't
have a strong opinion on how the modules are named/organized.
@bruno Breaking up the lldb module in the future is the plan. I'm just not sure
when I get around to do that. But the modulemap in the current state should
bring most of the module benefits to LLDB (build time, better code checks), so
I just opened a review for it.
Someone else with more LLDB experience could also break the cyclic
dependencies. The report I linked should point out quite well what exactly the
problematic includes are, so that person wouldn't even need to enable modules
for that.
================
Comment at: include/lldb/module.modulemap:66
+// This big module is necessary to work around the cyclic dependencies
+// between its submodules.
+module lldb {
----------------
bruno wrote:
> Will this trick be enough for local submodules visibility mode as well?
From my (very limited) experience with disabled local submodule visibility I
would say yes, but I can't test it on my current system (compilation already
fails at the first LLVM module without LSV).
https://reviews.llvm.org/D47929
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
