labath added a comment. In a way, this makes sense, but in a lot of other ways, it actually makes things worse :)
My long-term goal is to be able to build lldb-server without even having clang checked out (because it doesn't really need anything clang-related), and this would certainly make that impossible. Having Core depend on clang does not worry me much because it depends on so many things already, so the way I was thinking of resolving that is to move low-level things out of it (my tentative list includes things like Event/Listener/Broadcaster, State, Communication). That would leave Core with containing only the high-level stuff for which a clang dependency is not that surprising (although I agree that a ModuleList is not the best place for such a dependency). I guess it would be nice to encapsulate this in some sort of a plugin (since the setting is used from the clang expression parser plugin, I guess this would be the natural home for it) , but I haven't looked in detail at could that work. What I do know is that we already have the ability to inject settings from within a plugin (see SymbolFileDWARF::DebuggerInitialize). Maybe that would work here too? PS: This patch would make the clang modules path similar to the python directory computation, but this is also something that I've been meaning to change somehow (lldb-server does not need python either). ================ Comment at: source/Core/ModuleList.cpp:88 - llvm::SmallString<128> path; - clang::driver::Driver::getDefaultModuleCachePath(path); - SetClangModulesCachePath(path); + SetClangModulesCachePath(HostInfoBase::GetDefaultClangModuleCachePath()); } ---------------- You should reference this through the `HostInfo` typedef to get the "static polymorphism" to work. https://reviews.llvm.org/D47235 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
