[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

Chandler Carruth chandlerc at google.com
Thu Aug 30 15:20:34 PDT 2012


On Thu, Aug 30, 2012 at 3:02 PM, Ted Kremenek <kremenek at apple.com> wrote:

> 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.
>

Nope, I'm quite happy putting this in the core sublibrary. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120830/b28815bc/attachment.html>


More information about the cfe-commits mailing list