[llvm-dev] [RFC] Strategies for Bootstrapping Compiler-RT builtins

Vasileios Kalintiris via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 2 13:45:20 PST 2015


> Setting the *_FORCED variables is roughly equivalent to setting the *_WORKS variables. I’d really like it if we didn’t need to set those.

Yes, I believe the *_FORCED variables are a little bit more intrusive than the *_WORKS variables.

>> IMHO, from the options that you've mentioned, (3) is the cleanest one.
>> Conceptually, as you mentioned the builtins library does not belong with the
>> sanitizers and it would make sense splitting them in separate repositories.
>> Would it be too difficult to create an initial split given that we already
>> provide/support the COMPILER_RT_BUILD_BUILTINS and COMPILER_RT_BUILD_SANITIZERS
>> options?
>
> I think there is a lot of work involved here. We’ll need to generalize and split up
> some of the configuration content (stuff like config-ix.cmake) into the bits that apply
> everywhere, the bits that are needed only for builtins, and the bits that are only
> needed for sanitizers. I’m willing to start tackling that work if this is what
> the community thinks the right approach is.
>

Uh, you're right. I forgot about the common checks in config-ix.cmake.

>> I don't have enought experience with CMake so I don't know how feasible this is,
>> but for the last two categories it would be nice to keep in mind that the user
>> might have a C library other than Glibc.
>
> I’m certainly not going to expect the user has Glibc. I do all my work on Darwin platforms and we don’t have Glibc.

What I meant here is that some user might want to use another C library, other than the one installed in the system.
This would require us to be able to build the C library in between the LLVM projects, ie. after builtins. This
is just a suggestion as I don't know how much work/effort this would take (or if it requires any work at all).

- Vasileios


More information about the llvm-dev mailing list