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.