After like ~three reverts of D67422, the last known problem with that patch is a circular dependency that that patch introduces: libCrossTU -> libFrontend -> libSema -> libAnalysis -> libCrossTU. Namely, D67422 causes libAnalysis to depend on libCrossTU due to PlistDiagnosticConsumer (which is moved into libAnalysis in that patch) potentially requiring cross-TU macro expansion information to bundle with the plist.
Circular dependencies are bad because they're not allowed under -DBUILD_SHARED_LIBS. It's likely that this problem can be resolved purely on cmake side and i simply wasn't trying hard enough to find a solution (on the other hand, say, libTooling had to deal with this by introducing libToolingCore - a smaller sub-library with less dependencies).
But, anyway, given that the dependency is extremely tiny, i suggest resolving it by adding a tiny abstraction layer that'd eliminate the dependency entirely. Namely, i'd like to add a virtual interface under CrossTranslationUnitContext. Such interface is defined in libAnalysis and implemented by the CrossTranslationUnitContext class in libCrossTU. This vaguely makes sense because libAnalysis is a low-level collection of analysis algorithms whereas libCrossTU is high-level, even frontend-level management of entire clang invocations so calling from libAnalysis to libCrossTU feels like layering violation.
In this patch i add only one function to the interface. If you guys want i can move all (or at least some) public methods of CrossTranslationUnitContext into that interface but there's no immediate need for that.
Why don't we have a dependency in libCrossTU to libAnalysis? In the CMakeLists.txt?
Here we implement the CrossTUAnalysisHelper's abstract virtual function thus we include the CrossTUAnalysisHelper.h. But
CMake should know about the dependency even if this is only a header only dependency, shouldn't it? (We were talking about this with @steakhal.)