[LLVMdev] RFC: Timeline for deprecating the autoconf build system?

[Reid Kleckner]

On Tue, Nov 4, 2014 at 1:17 PM, Dan Liew <dan at su-root.co.uk> wrote:

> On 4 November 2014 19:08, Brooks Davis <brooks at freebsd.org> wrote:
> > On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote:
> >> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de>
> wrote:
> >>
> >> > Requiring cmake for NetBSD is not acceptable as it is almost as heavy
> as
> >> > a C++ compiler itself. That said, I don't really care about the
> >> > Makefiles, just about configure and the associated loggic to craete
> >> > Config.h and friends. I would expect FreeBSD to have similar concerns.
> >>
> >> For the FreeBSD base system, we use a bmake-based build system for
> >> LLVM, but that is based on the Makefiles generated by CMake.  I
> >> believe that we're now using CMake for the version of LLVM in ports.
> >
> > For most versions we're using autoconf because it lets us build clang
> > against an installed LLVM.  The autoconf build system almost supports
> this
> > (you need to symlink a couple installed files into the build tree), but
> > AFACT the cmake build system doesn't.
> >
> > It would be really useful if I could build clang against an installed
> LLVM
> > and LLDB against an install clang and LLVM.
>
> CMake can support this. We need to make use of the "exporting targets"
> feature
> that CMake offers so that clients can build against LLVM libraries.
> LLVM has actually been exporting this information for a while and it
> is documented here [1].
>
> To further complicate matters the clang CMake build system supports
> two modes. In tree build (i.e. inside tools/clang) and an out of tree
> build. The problem IIRC with the out of tree build is that the CMake
> clang build system does not try to use this information at all and
> instead tries to get its information from the llvm-config executable
> which doesn't feel very clean.  I should warn that I've never tried
> the "out of tree" build of clang so I don't know how well it works.


I agree, I wanted to spend some time today trying to make this work.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/7ec60b14/attachment.html>