<div dir="ltr"><div dir="ltr"><div>I also forgot to mention, another reason to do separate standalone builds is during bootstrapping. When building clang for the first time, Glibc and Linux kernel headers for some of the target architectures we support are not available.</div><div><br></div><div>We therefore have to do multiple builds in order like:</div><div>1. Build clang for host ISA and install it in SDK.<br></div><div>2. Build the rest of the SDK with the clang we just built.</div><div>(much much later)</div><div>3. Build and install glibc and linux headers for each supported target ISA.</div><div>4. Build and install libc++ for each supported target using the clang that we built in step 1. </div><div><br></div><div>So at this point we are just done building clang and other libraries that we need in the SDK that supports multiple architectures.</div><div>This SDK is then packaged and used in many projects inside Google, not just Chrome OS.</div><div><br></div><div>Now for a target Chromebook, we do not copy over the generic libc++ we have in SDK but do a re-build.</div><div>This also let us use the accurate ISA flags for the chromebook that are used e.g. march=skylake or mcpu=cortex... etc.</div><div></div><div><br></div><div>The steps for a Chromebook build looks like:</div><div>1. Build and install glibc in target root</div><div>2. Build and install libc++ in target root (we do not want to build llvm/clang etc.)<br></div><div>3. Build the rest of the target system linking with the libc++ we built for target.</div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 6:30 PM Petr Hosek <<a href="mailto:phosek@chromium.org">phosek@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This is one of the use cases for the runtimes build. You can invoke CMake as:</div><div><br></div><div>cmake \</div><div>-DLLVM_ENABLE_PROJECTS=clang \</div><div>-DLLVM_ENABLE_RUNTIMES=libcxx \</div><div>-DLLVM_RUNTIME_TARGETS=aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unknown-linux-gnu;x86_64-unknown-linux-gnu \</div><div>path/to/llvm-project/llvm</div><div><br></div><div>This is going to compile Clang, and then use the just-built Clang to cross-compile libc++ to four different targets. There are a lot of other customization options. You can also pass-through additional flags to individual targets, but this gets complicated quickly, so we usually put this logic into a cache file (see for example <a href="https://github.com/llvm/llvm-project/blob/master/clang/cmake/caches/Fuchsia-stage2.cmake" target="_blank">https://github.com/llvm/llvm-project/blob/master/clang/cmake/caches/Fuchsia-stage2.cmake</a>) and then invoke CMake as:</div><div><br></div><div><div>cmake \</div><div>-C path/to/llvm-project/clang/cmake/caches/Fuchsia-stage2.cmake \</div><div>path/to/llvm-project/llvm</div><div><br></div><div>Aside from the fact that you can do everything in a single CMake build without any additional wrapper scripts, another advantage is that anyone can easily reproduce your build without needing anything else other than the LLVM monorepo.</div></div></div></blockquote><div><br></div><div>I thought I mentioned it but we do not want to be cross-compiling llvm/clang here, just libc++. We'll use system clang that we already built and installed in the SDK.</div><div><br></div><div>Thanks,</div><div>Manoj</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 6:13 PM Manoj Gupta <<a href="mailto:manojgupta@google.com" target="_blank">manojgupta@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We use standalone builds in Chrome OS to build libc++ for different ISA targets. One reason to do so is to cross-compile libc++ only for the target Chromebooks. <div>We do not want to cross-compile all of clang/llvm as they are not going to be shipped on device.<div><br></div><div>The cmake invocation roughly looks like:</div><div>cmake <monorepo-root>/libcxx -DLLVM_ENABLE_PROJECTS=libcxx -DCMAKE_INSTALL_PREFIX=/path/to/target_root/usr</div><div><br></div><div>Thanks,</div><div>Manoj</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 4:12 PM Petr Hosek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Shoaib for a great summary. To summarize this as an answer to Louis' questions:</div><div><br></div><div><div>1. What is a "Standalone build"? What does it enable that a normal monorepo build can't?</div><div><br></div><div>This means building any of the runtimes separately, where the runtime's CMakeLists.txt (e.g. path/to/my/llvm-project/libcxx/CMakeLists.txt) is the top-level one. The reason for using this variant is the ability to build individual runtimes without the rest of LLVM (e.g. building only libc++) which is not something that the monorepo build can do.</div><div><br></div><div>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?</div><div><br></div><div>This means building runtimes with the just-built Clang. The reason why this is complicated is because at the point when you run CMake for runtimes (i.e. where path/to/my/llvm-project/llvm/runtimes/CMakeLists.txt is the top-level one), you may not have a fully working toolchain yet.</div><div><br></div><div>For example, in case of Fuchsia, our sysroot contains only libc, so when we're doing the runtimes build, and one of the runtimes tries to use check_cxx_compiler_flag, which behind the scenes tries to compile and link a small C++ binary, that check is going to fail not because the flag isn't supported, but because we don't have libc++ yet (that's what we're trying to build right now). So we need to be really careful and avoid introducing cycles e.g. where libc++ CMake build depends C++ standard library (even if that dependency is not explicit).</div><div><br></div><div>Note that this is going to become significantly easier after we upgrade CMake because 3.6 introduced <a href="https://cmake.org/cmake/help/v3.6/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html" target="_blank">https://cmake.org/cmake/help/v3.6/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html</a> which allows building static archives instead of executables when running check_* functions which can help and break these cycles.</div><div><br></div><div>3. Are there other "hidden" ways to build the runtime libraries?</div><div><br></div><div>Not "hidden", but there's the default way which most developers use where you use the same host compiler to build both Clang and your runtimes. I think this mode should go away because it's too fragile: it silently relies on your host compiler and the Clang you just built using the same ABI, which isn't guaranteed (unless you're using a multi-stage build) and I'm surprised we haven't yet seen issues due to this (or maybe we did and people just aren't aware of the problem).</div></div><div><br></div><div><div>(Why do we need HAVE_* flags?)</div><div><br></div><div>It's because in the runtimes build, there's no guarantee about the order in which runtimes are being built, so you cannot use e.g. <font face="monospace">if (TARGET cxxabi_shared)</font> 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).</div></div><div><br></div><div>There's more discussion related to this in <a href="https://reviews.llvm.org/D68833" target="_blank">https://reviews.llvm.org/D68833</a>, once we update CMake to >=3.11 we'll eliminate all HAVE_* variables and replace them with generator expressions which is a much better solution.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 1:21 PM Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">(CCing Chris and Petr, who’ve done the most work on the runtimes build)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">At least for me on Linux, using LLVM_ENABLE_PROJECTS is actually the unusual way of building libc++; I use LLVM_ENABLE_RUNTIMES. The reason is, my host compiler is often gcc, but I want to build, test, and ship libc++ with the clang I just
 built.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The runtimes build is when you use LLVM_ENABLE_RUNTIMES. It sets up the build of all runtimes (compiler-rt, libc++, libc++abi, libunwind, etc.) as a CMake ExternalProject which depends on the build of clang and other toolchain tools. In
 other words, if I run the following:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">cmake -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi' path/to/my/llvm-project/llvm<u></u><u></u></p>
<p class="MsoNormal">ninja cxx<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The build system will automatically build clang and other toolchain tools (e.g. llvm-ar), run the ExternalProject configuration with e.g. CMAKE_C_COMPILER and CMAKE_CXX_COMPILER set to the just-built clang, and then build libc++ with that
 configuration (so with the just-built clang). It’s a pretty convenient workflow for my setup. It also takes care of e.g. automatically rebuilding libc++ if you make changes to clang and then run `ninja cxx` again.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As for why the runtimes build use the “standalone build” setup, it’s because there’s a separate CMake configuration happening for the runtimes in this setup (which is necessary in order to be able to configure them to use the just-built
 toolchain), so e.g. clang isn’t available as an in-tree target. See <a href="https://reviews.llvm.org/D62410" target="_blank">
https://reviews.llvm.org/D62410</a> for more details. Your top-level CMakeLists.txt in the runtimes build is llvm/runtimes/CMakeLists.txt and not libcxx/CMakeLists.txt (as it would be in a fully standalone build), but it’s also not llvm/CMakeLists.txt (as it
 would be with LLVM_ENABLE_PROJECTS).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">At the CMake round table at the dev meeting last October, we’d discussed the runtimes builds, and Chris had advanced that there should be two supported ways to build the runtimes:<u></u><u></u></p>
<ol style="margin-top:0in" start="1" type="1">
<li style="margin-left:0in">If you’re building as part of the LLVM build and using LLVM_ENABLE_RUNTIMES<u></u><u></u></li><li style="margin-left:0in">If you’re building fully standalone (as in you’re pointing CMake to libc++’s source directory, so that your top-level CMakeLists is libcxx/CMakeLists.txt)<u></u><u></u></li></ol>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I agree with that position. In particular, I think LLVM_ENABLE_PROJECTS is definitely the wrong thing to use for compiler-rt, which is strongly tied to your just-built compiler. I think it’s arguably the wrong thing to use for libc++/libc++abi/libunwind
 as well, where you either want to use your just-built Clang (which LLVM_ENABLE_RUNTIMES was made for), or a different compiler (in which case you’d do a fully standalone build), but silently using your host compiler for them is probably not what you want.
 (The LLVM_ENABLE_PROJECTS workflow for libc++/libc++abi/libunwind probably works out better on macOS, where your host compiler is a recent Clang anyway so the difference between it and a just-built Clang aren’t as marked, but I’ve had issues even on macOS
 in the past where using the host compiler via LLVM_ENABLE_PROJECTS gave me weird libc++ test errors, and LLVM_ENABLE_RUNTIMES just worked.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">What do you think?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-left:0.5in"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Louis Dionne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Reply-To: </b>Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>><br>
<b>Date: </b>Wednesday, April 8, 2020 at 8:46 AM<br>
<b>To: </b>Libc++ Dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>><br>
<b>Cc: </b>llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>[llvm-dev] Clarifying the supported ways to build libc++, libc++abi and libunwind<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">[Cross-post to llvm-dev to make sure everybody relevant sees this]<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Hi,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:Monaco">    $ mkdir build</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:Monaco">    $ cd build</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:Monaco">    $ cmake <monorepo-root>/llvm -DLLVM_ENABLE_PROJECTS=libcxx;libcxxabi;libunwind <options></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:Monaco">    $ ninja -C build install-{cxx,cxxabi,unwind}</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">1. What is a "Standalone build"? What does it enable that a normal monorepo build can't?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">3. Are there other "hidden" ways to build the runtime libraries?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Louis<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
</div>
</div>

</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div></div>