search for: llvm_enable_runtim

...ch runtimes are being built, so you cannot use e.g. if (TARGET cxxabi_shared) from within libc++ build because you don't have any guarantee whether libc++abi has already been processed. So instead, runtimes build sets these flags for each runtime being built (that is each runtime specified in -DLLVM_ENABLE_RUNTIMES=) and you can at least check whether that runtime is being built at all (e.g. you can check from within libc++ whether libc++abi is also being built as part of the runtimes build). There's more discussion related to this in https://reviews.llvm.org/D68833, once we update CMake to >=3.11 w...

[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

...monolithic set of libraries when you are bootstrapping. In order to even configure the LLVM sanitizer runtimes you need libc and many other OS interfaces, so when bootstrapping you need to build the compiler-rt builtins library separately from the sanitizers. This can be done either by using the `LLVM_ENABLE_RUNTIMES` CMake option (see DistributionExample-stage2.cmake in clang/cmake/caches), or by treating compiler-rt/lib/builtins as the top-level CMake file. I would strongly suggest that you start with one of the CMake cache files under clang/cmake/caches as an example because setting up the CMake options t...

...sting ones, so if the new path doesn't exist, the driver will simply fallback to the existing behavior. When this is done, we need to modify the CMake build to install files into the new location. This layout would be only used when runtimes are built as part of the llvm/runtimes tree or using LLVM_ENABLE_RUNTIMES in the monorepo layout (because this setup supports cross-compiling runtimes). When built as part of LLVM or standalone, libc++, libc++abi, libunwind would still install their files to $prefix/include and $prefix/lib as today. Once the overall scheme is agreed upon, we could also consider de-dup...

...the driver will simply fallback to the existing > > behavior. When this is done, we need to modify the CMake build to > > install files into the new location. > > > > This layout would be only used when runtimes are built as part of the > > llvm/runtimes tree or using LLVM_ENABLE_RUNTIMES in the monorepo layout > > (because this setup supports cross-compiling runtimes). When built as > > part of LLVM or standalone, libc++, libc++abi, libunwind would still > > install their files to $prefix/include and $prefix/lib as today. > > > > Once the overall sch...

...ply fallback to the existing >> > behavior. When this is done, we need to modify the CMake build to >> > install files into the new location. >> > >> > This layout would be only used when runtimes are built as part of the >> > llvm/runtimes tree or using LLVM_ENABLE_RUNTIMES in the monorepo layout >> > (because this setup supports cross-compiling runtimes). When built as >> > part of LLVM or standalone, libc++, libc++abi, libunwind would still >> > install their files to $prefix/include and $prefix/lib as today. >> > >> >...