<div dir="ltr"><div dir="ltr">On Thu, Oct 28, 2021 at 6:35 AM Louis Dionne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><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 dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 28, 2021 at 4:22 AM Andrzej Warzynski <<a href="mailto:andrzej.warzynski@arm.com" target="_blank">andrzej.warzynski@arm.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">Hi Louis,<br>
<br>
This sounds like a huge simplification, thank you!<br>
<br>
With this change, will we still be able to use LLVM_ENABLE_PROJECTS to <br>
build libc++, libc++abi and libunwind? IIUC, you are disabling this <br>
option entirely, right? Will CMake warn us about the <br>
incorrect/deprecated usage? Should the LLVM documentation be updated [1]?<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif">Hi,</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">The goal is to deprecate and then entirely remove building the runtimes with LLVM_ENABLE_PROJECTS.</div></div></div></div></blockquote><div><br>Glad to hear that's on the plan - looking forward to removing the ambiguity/traps.<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 class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif"> Libc++'s own documentation has already been updated, but I will update the documentation you linked to and add a warning in the CMake -- thanks for the suggestion!</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">Cheers,</div><div style="font-family:arial,helvetica,sans-serif">Louis</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thank you,<br>
-Andrzej<br>
<br>
[1] <a href="https://llvm.org/docs/CMake.html" rel="noreferrer" target="_blank">https://llvm.org/docs/CMake.html</a><br>
<br>
On 11/10/2021 17:17, Louis Dionne via llvm-dev wrote:<br>
> Hi folks,<br>
> <br>
> This message is both a heads up and a request for comments on an <br>
> upcoming change we want to make to the way we build <br>
> libc++/libc++abi/libunwind.<br>
> <br>
> For a long time now, those three projects have supported various ways to <br>
> be built:<br>
> <br>
> 1. The Project build, where one would use <root>/llvm as the root of the <br>
> CMake invocation and pass LLVM_ENABLE_PROJECTS.<br>
> 2. The Standalone build, where one would perform one CMake invocation <br>
> per project being built, and fill in various CMake variables to tell <br>
> each project where to find bits of the other projects.<br>
> 3. The "Runtimes" or "Bootstrapping" build, where one would use <br>
> <root>/llvm as the root of the CMake invocation and pass <br>
> LLVM_ENABLE_RUNTIMES. This would result in Clang being built, and then <br>
> the runtimes being built with that fresh Clang.<br>
> 4. The "Unified Standalone" build, where one would use <br>
> <root>/libcxx/utils/ci/runtimes as the root of the CMake invocation and <br>
> pass LLVM_ENABLE_PROJECTS. This was introduced to work around the fact <br>
> that the Project build doesn't work on several embedded platforms, and I <br>
> think it is only used at Apple.<br>
> <br>
> Through the years, this has gotten rather confusing and difficult to <br>
> support. We currently support all of those on a best-effort basis and we <br>
> do have build bots checking each of them, however the complexity is <br>
> often getting in the way of providing proper support and improving the <br>
> build system of those projects. We've been trying to migrate to a <br>
> simpler way to build the runtimes that works for all use cases (notably <br>
> embedded platforms) for a long time, and we recently got to a point <br>
> where this is possible (thanks mainly to @phosek and @mstorsjo). To <br>
> summarize what we're aiming for, we'll now have two ways of building <br>
> libc++/lib++abi/libunwind:<br>
> <br>
> 1. The "Default" build, where the CMake invocation is rooted at <br>
> <root>/runtimes and one uses LLVM_ENABLE_RUNTIMES.<br>
> 2. The "Bootstrapping" build, where the CMake invocation is rooted at <br>
> <root>/llvm and one uses LLVM_ENABLE_RUNTIMES (this is the current <br>
> "Bootstrapping" build unchanged).<br>
> <br>
> If you have been using the "Project", "Standalone" or "Unified <br>
> Standalone" builds, you should be moving to the new "Default" build. <br>
> This should be really easy to achieve, basically you can just change <br>
> LLVM_ENABLE_PROJECTS to LLVM_ENABLE_RUNTIMES, perform a single <br>
> invocation of CMake instead of multiple invocations, and pass all the <br>
> LIBCXX_FOO, LIBCXXABI_FOO and LIBUNWIND_FOO options to that single CMake <br>
> invocation. See the release note in the PR linked below for more details.<br>
> <br>
> We are aiming to deprecate all the old ways to build as soon as <br>
> possible, and to keep supporting them until after the LLVM 14 release, <br>
> at which point we would like to remove support for those and get started <br>
> with making improvements. The review at <a href="https://reviews.llvm.org/D111356" rel="noreferrer" target="_blank">https://reviews.llvm.org/D111356</a> <br>
> <<a href="https://reviews.llvm.org/D111356" rel="noreferrer" target="_blank">https://reviews.llvm.org/D111356</a>> enshrines this deprecation in the <br>
> documentation. For technical discussion on this proposed change, please <br>
> comment on that review to keep everything in one place.<br>
> <br>
> Cheers,<br>
> Louis<br>
> <br>
> Questions you might be asking yourself:<br>
> <br>
> Q: Why doesn't the Project build work for embedded platforms?<br>
> A: A lot of CMake code in <root>/llvm expects that we're building for a <br>
> target with the usual capabilities for a build host, but that isn't the <br>
> case for several embedded targets. While it doesn't make sense to build <br>
> LLVM or Clang for those embedded targets (which would never be used as <br>
> build hosts), it makes sense to build the runtimes for those targets if <br>
> you are cross-compiling.<br>
> <br>
> Q: Currently, we use the Standalone build and are not required to have <br>
> all of the Monorepo available. Does this change our ability to do that?<br>
> A: Not in the mid term. Building any of the runtimes already requires <br>
> all the runtimes to be co-located. The only thing you could get away <br>
> with previously was not having the part in <root>/llvm. With the <br>
> "Default" build, this will be possible as soon as we move a few CMake <br>
> helpers from <root>/llvm/cmake to <root>/cmake. Then, you'll only have <br>
> to have <root>/runtimes, <root>/cmake and the projects you are building.<br>
> <br>
> Q: What's the difference between the "Runtimes build" and the <br>
> "Bootstrapping build"?<br>
> A: None. We're trying to move away from the term "Runtimes build" <br>
> because it's waaaay too confusing, and doesn't describe the fact that <br>
> we're really building the runtimes with a just-built Clang.<br>
> <br>
> Q: What's up with naming the new default build the "Default build"?<br>
> A: The name sucks, but we had to pick one and the "Runtimes build" was <br>
> already taken for the build that does a bootstrap. Suggestions are <br>
> welcome -- basically what this performs is a normal build of the <br>
> runtimes using your system compiler, like you used to do with <br>
> LLVM_ENABLE_PROJECTS (but it's better).<br>
> <br>
> Q: What are the benefits of this migration beyond simplifying the code <br>
> for maintainers?<br>
> A: Reducing the number of ways we can build the runtimes means that all <br>
> the workflows for building the runtimes will become simpler for users <br>
> (especially vendors). Furthermore, the new "Default" build is as simple <br>
> as the old Project build, but it is faster to configure and works on <br>
> embedded platforms. In the near future, it should also be possible to <br>
> perform the equivalent of an old "Project build" without having all of <br>
> the monorepo available.<br>
> <br>
> Q: Does this affect other "runtimes" projects like compiler-rt?<br>
> A: Not for the time being. We will probably attempt to move those over <br>
> in the future as well, however for the time being I can only confirm <br>
> that this works fine for libc++, libc++abi and libunwind, so that's <br>
> where my deprecation efforts are focused.<br>
> <br>
> <br>
> _______________________________________________<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>
> <br>
</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></div>