<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 21, 2012, at 11:40 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif"><font size="2">On Thu, Jun 21, 2012 at 10:21 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><br><div><div>On Jun 20, 2012, at 5:13 PM, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="font-family:arial,helvetica,sans-serif"><font><div>Is there anybody who is certain that our autoconf dependency needs to stay around? Are there developers stuck on systems that don't have a recent enough cmake in their most recent release, or maybe are using some features from configure+make that the cmake build system doesn't implement?</div>
<div><br></div><div>If nobody pipes up, I might actually try actually removing it!</div></font></div></blockquote><br></div></div><div>I think this is premature, although I consider it a worthy goal. Right now, the only motivation we have for removing "configure+make" is that we don't like having two build systems, but that's not good enough.</div>
</div></blockquote><div><br></div><div>Here here. Thanks for writing up this detailed and accurate response.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Some things that CMake needs to do well for it to become the only way to build LLVM/Clang:</div><div> - Optionally build and install compiler-rt </div><div> - Optionally build and install libc++</div>
</div></blockquote><div><br></div><div>FYI, I'm currently in-flight working on the first of these, and planning to work on the second afterward.</div></div></font></div></blockquote><div><br></div>Great!</div><div><br><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap:break-word"><div> - Ease-to-use cross-compilation support</div><div> - Documentation to make it easy to understand how to do the above</div><div> - LLDB?</div><div> - LLVM testsuite support</div>
</div></blockquote><div><br></div><div>I think David might be interested in this. However, the way LNT is structured, I don't think this is a requisite: it is now much more common to build the testsuite independently of llvm/clang, and hand it a set of pre-built binaries.</div></div></font></div></blockquote><div><br></div><div>Okay, that's reasonable.</div><br><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div>And some value-add that might make CMake motivating for others:</div>
<div> - Easy bootstrap</div><div> - Build packages/installers</div></div></blockquote><div><br></div><div>A couple more:</div><div><br></div><div>- Support for ninja if you happen to have it (and no cost if you don't) gives you faster rebuilds.</div>
<div>- Slightly better support for the new Tooling infrastructure.</div></div></font></div></blockquote><br></div><div>Your Tooling comment brings up a more general thing. One way CMake could be more motivating is if it made it *easy* to create new Clang tools (based on tooling), Clang plugins (when they come along), and also LLVM tools.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>