[cfe-commits] r160851 - in /cfe/trunk/lib: ARCMigrate/CMakeLists.txt AST/CMakeLists.txt Analysis/CMakeLists.txt CodeGen/CMakeLists.txt Driver/CMakeLists.txt Edit/CMakeLists.txt Frontend/CMakeLists.txt FrontendTool/CMakeLists.txt Lex/CMakeLists.tx

[Chandler Carruth]

Please keep the mailing list on the CC-line...

On Thu, Jul 26, 2012 at 11:42 PM, NAKAMURA Takumi <geek4civic at gmail.com>wrote:

> Chandler,
>
> I think it would not be the right way that preceding(dependent) rules
> and actions satisfy generating headers.
>
> My intention is; Each of modules should have rules for itself to
> generate required headers.
>

I think we fundamentally disagree here. What rules generate which AST
headers is an implementation detail of the AST library (for instance). I do
not want that information leaked to users of the AST library, they should
just depend on the AST library and be done with it.


> I am working for;
>
>   - LLVMBuild-izing clang
>

Why? I think this would be a step in the wrong direction. Currently Clang
has no need of this -- adding it would add complexity and overhead to the
understanding of the build system for no tangible gain.


>   - Cutting inter-libs deps


I think we need to preserve proper layering and *simple* deps that are
easily understood. I also think we need the system to be simple, easy to
understand, and easy for developers to get right. What you're proposing
doesn't provide enough encapsulation for this.

With them, "make -j100" reaches loadavg to 100.0 :p
>

I have no such load problems today. I think there must be some other cause
that only happens to be solved by the changes you are making, and frankly,
I don't think the changes justify the cost.


> I shall propose patches when I am ready. Please discuss then.
>

No, we should discuss here. ;] You're already committing changes that
violate the encapsulation we previously had, and otherwise shifting the
cmake build in a direction that we've talked about before, and I've
expressed specific objections to. I think we need to resolve the direction
issues now. =D

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120726/0c8cd225/attachment.html>