[llvm-dev] Clarifying the supported ways to build libc++, libc++abi and libunwind

[Louis Dionne via llvm-dev]

[Cross-post to llvm-dev to make sure everybody relevant sees this]

Hi,

I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of supported use cases for building the runtime libraries are. In particular, the world I would like to live in is one where the only way to build libc++/libc++abi/libunwind is:

    $ mkdir build
    $ cd build
    $ cmake <monorepo-root>/llvm -DLLVM_ENABLE_PROJECTS=libcxx;libcxxabi;libunwind <options>
    $ ninja -C build install-{cxx,cxxabi,unwind}

The "runtimes" build would be built on top of this -- it would be just a driver for building these libraries using documented options against the just-built Clang. I think it already does so in essence, however if I'm not mistaken it uses the "Standalone build" and it definitely sets some magic and undocumented CMake variables (like HAVE_LIBCXXABI) that we have to be really careful not to break.

So, to better understand what people use today, I have some questions. I know the answer to some of those, but I want to see what others have to say:

1. What is a "Standalone build"? What does it enable that a normal monorepo build can't?
2. What is the "Runtimes" build? How does it work, what is it used for, and what does it expect from libc++/libc++abi/libunwind?
3. Are there other "hidden" ways to build the runtime libraries?

Cheers,
Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/2062a647/attachment.html>