<div>Please keep the mailing list on the CC-line...</div><div><br></div>On Thu, Jul 26, 2012 at 11:42 PM, NAKAMURA Takumi <span dir="ltr"><<a href="mailto:geek4civic@gmail.com" target="_blank" class="cremed">geek4civic@gmail.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chandler,<br>
<br>
I think it would not be the right way that preceding(dependent) rules<br>
and actions satisfy generating headers.<br>
<br>
My intention is; Each of modules should have rules for itself to<br>
generate required headers.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am working for;<br>
<br>
  - LLVMBuild-izing clang<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  - Cutting inter-libs deps</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With them, "make -j100" reaches loadavg to 100.0 :p<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I shall propose patches when I am ready. Please discuss then.<br></blockquote><div><br></div><div>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</div>
<div><br></div><div>-Chandler</div></div></div>