[llvm-commits] [llvm] r47342 - in /llvm/trunk: include/llvm/ include/llvm/Support/ lib/AsmParser/ lib/Bitcode/Writer/ lib/Transforms/IPO/ lib/Transforms/Scalar/ lib/VMCore/ tools/llvm2cpp/

[Dale Johannesen]

On Feb 20, 2008, at 11:03 AM, Chris Lattner wrote:
>>> other headers only include the former "light" header, and only .cpp
>>> files #include the full header.  Is this reasonable?
>>
>> It seems natural to me to keep all the types that manipulate
>> ParamAttrs together, and I really doubt there's a noticeable
>> performance issue.  I guess I can do this, but why do you want to?
>
> The general idea is to keep coupling of the various components in LLVM
> as loose as possible.  There are a variety of ways to do this, and C++
> is not a perfect vehicle for this (it would be really nice to have
> forward declared enums for example).  However, the general policy is:
>
> 1. #include as little as possible in headers, which forces .cpp files
> to #include what they need.
> 2. .cpp files should #include as little as possible.
> 3. Factor headers so that they different clients which need different
> subsets only pull in what they need.
> 4. Separate headers from their implementation files, so that libraries
> can have private headers... while keeping the distinction between
> public and private headers clear.
> 5. Make the include hierarchy reflect the logical library structure.
>
> None of these are absolute hard requirements or rules, they are more
> of guiding principles.  In this case, pulling in FoldingSet.h into
> Instruction.h means that just about everything that manipulates the IR
> will get it.  This means that .cpp files should have their #include
> removed (by #2) and it thus makes it less obvious what is happening.

Wow, that's complicated.   I've always favored a simple rule:

Anything that refers to a type is responsible for including the header  
that declares it.

OK, I'll set this up your way, eventually.