<div dir="ltr"><div class="gmail_extra">Just to try and share some perspective of developers on Clang and LLVM...</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 7:20 AM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2oq" style="overflow:hidden">IIUC there is a desire for Clang to be able to be built externally to<br>
LLVM rather than subsumed into its build process.  The top-level<br>
CMakeLists.txt file of Clang already has code to do that, though it<br>
can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake<br>
are integrated.</div></blockquote><div><br></div><div>While there is a strong desire to do this by some developers, it is purely for pragmatic reasons: it makes their builds *significantly* faster because xcode doesn't load the entire project, etc.</div>
<div><br></div><div>I don't believe there is *any* interest in breaking the hard version lock between LLVM and Clang. We rely on that heavily, and it's likely never going away.</div><div><br></div><div>I think the default and expected build mode should still be a merged tree where the bits and pieces desired are checked out into an LLVM checkout, and the build system can handle whatever partial build there is provided the dependencies are in place.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2oq" style="overflow:hidden">Then it will even be possible to build Clang using<br>
CMake against a LLVM that was built and installed using configure+make.</div></blockquote></div><br>I actually doubt that this is a particularly interesting build configuration. Perhaps it is for distributions or packagers, but frankly, I expect it to bitrot immediately. I don't think any devs will realistically use it. Maybe I'm wrong though...</div>
</div>