[cfe-commits] r162928 - in /cfe/trunk: include/clang/Frontend/AnalyzerOptions.h include/clang/Frontend/CompilerInvocation.h include/clang/StaticAnalyzer/AnalyzerOptions.h include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h lib/Stati

Ted Kremenek kremenek at apple.com
Thu Aug 30 15:02:11 PDT 2012


On Aug 30, 2012, at 2:50 PM, Ted Kremenek <kremenek at apple.com> wrote:

> On Aug 30, 2012, at 2:29 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> Yea, the only problem is that the SA/Frontend library depends heavily on the Frontend library. We build all of the SA into a single library, but we probably shouldn't. Because we do that, when we check the library-level include layering, we find a cycle.
> 
> I'm not certain why the SA/Frontend library was created in the first place.  Originally the Frontend library depended on the StaticAnalyzer, and there was no cycle.  Conceptually SA/Frontend is more part of the Frontend then the static analyzer, and that's how it was actually implemented at one point.  At some point it seemed reasonable to move the static analyzer specific parts of the Frontend into SA/Frontend out of the core Frontend library.  This over-refactoring is what has led to this confusion.
> 
>> 
>> Here is one question perhaps, which of the 3 SA sub-libraries should this header belong to?
>> 
> 
> Probably StaticAnalyzerCore.
> 

My unproductive vitriol aside, would it help for me to create a 4th (leafy) library to include this leaf header?  It's not completely silly, and would hopefully resolve this structuring issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120830/cae61782/attachment.html>


More information about the cfe-commits mailing list