[llvm-dev] [RFC] A vision for building the runtimes

[Louis Dionne via llvm-dev]

> On Oct 23, 2020, at 12:36, Dominik Montada <dominik.montada at hightec-rt.com> wrote:
> 
> 
> 
> Am 23.10.20 um 16:30 schrieb Louis Dionne:
>> 
>> 
>>> On Oct 23, 2020, at 02:25, Dominik Montada <dominik.montada at hightec-rt.com <mailto:dominik.montada at hightec-rt.com>> wrote:
>>> 
>>> Hi Louis,
>>> 
>>> big +1 from me. I recently set up the runtimes for our downstream toolchain and to be honest it was quite a pain to get everything working. Due to the complexity we ended up creating our own CMake cache to make the configuration easier. We also tried to use the existing toolchain build. But since it tries to build the runtimes immediately after it built the compiler we cannot use it, as we have to build our C library first. So having a "unified standalone" approach sounds just like something that would make this use-case a lot easier.
>> 
>> Glad to see support!
>> 
>>> 
>>> Do you already have an idea of how a multilib build would look like with your proposed setup?
>> 
>> Can you define what you mean by a multilib build? Do you mean building for several architectures at once? Do you produce the libs for each architecture in different directories?
> Yes, but also more than that: our target has different architectures, so we build each library for each architecture. But on top of that, we also build the libraries with different configurations, e.g. with or without exceptions. The Fuchsia toolchain is doing something similar IIRC. We produce these libraries in different directories per architecture and per configuration, so for example:
> 
> target/arch1/except
> target/arch1/noexcept
> target/arch2/except
> target/arch2/noexcept
> 
>> 
>> If you're talking about what I'm thinking of, I believe the simplest and most CMake-friendly way of doing it would be to have multiple CMake invocations. We can hide those behind a "driver" build like what the Runtimes build does, for example, but the libc++/libc++abi/libunwind builds themselves wouldn't be aware they're being built for multiple archs.
> With the use-case described above, we simply do one CMake invocation for each library configuration.

Yes, I think one CMake invocation per configuration is the way to go. Unlike other build systems, it seems like CMake wasn't really designed with multi-configuration builds in mind.

Now, one can wrap these multiple CMake invocations in a single one by using a "driving" CMakeLists.txt and calls to ExternalProject_add if so desired, but it's really another layer on top.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201023/7d7fe683/attachment.html>