<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 4, 2014 at 1:17 PM, Dan Liew <span dir="ltr"><<a href="mailto:dan@su-root.co.uk" target="_blank">dan@su-root.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 November 2014 19:08, Brooks Davis <<a href="mailto:brooks@freebsd.org">brooks@freebsd.org</a>> wrote:<br>
> On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote:<br>
>> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
>><br>
>> > Requiring cmake for NetBSD is not acceptable as it is almost as heavy as<br>
>> > a C++ compiler itself. That said, I don't really care about the<br>
>> > Makefiles, just about configure and the associated loggic to craete<br>
>> > Config.h and friends. I would expect FreeBSD to have similar concerns.<br>
>><br>
>> For the FreeBSD base system, we use a bmake-based build system for<br>
>> LLVM, but that is based on the Makefiles generated by CMake.  I<br>
>> believe that we're now using CMake for the version of LLVM in ports.<br>
><br>
> For most versions we're using autoconf because it lets us build clang<br>
> against an installed LLVM.  The autoconf build system almost supports this<br>
> (you need to symlink a couple installed files into the build tree), but<br>
> AFACT the cmake build system doesn't.<br>
><br>
> It would be really useful if I could build clang against an installed LLVM<br>
> and LLDB against an install clang and LLVM.<br>
<br>
</span>CMake can support this. We need to make use of the "exporting targets" feature<br>
that CMake offers so that clients can build against LLVM libraries.<br>
LLVM has actually been exporting this information for a while and it<br>
is documented here [1].<br>
<br>
To further complicate matters the clang CMake build system supports<br>
two modes. In tree build (i.e. inside tools/clang) and an out of tree<br>
build. The problem IIRC with the out of tree build is that the CMake<br>
clang build system does not try to use this information at all and<br>
instead tries to get its information from the llvm-config executable<br>
which doesn't feel very clean.  I should warn that I've never tried<br>
the "out of tree" build of clang so I don't know how well it works.</blockquote><div><br></div><div>I agree, I wanted to spend some time today trying to make this work.</div><div><br></div><div>I think part of the issue is that the current standalone clang build is designed to work when all you have is a build directory, not an install directory. This way you can have two XCode IDE instances: one for LLVM and once for Clang, and just hit build in LLVM before building Clang. It's one level of manual dependency management, but worth it for the increase in responsiveness.</div></div></div></div>