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

[Chris Bieneman via llvm-dev]

> On Nov 2, 2015, at 1:45 PM, Vasileios Kalintiris <Vasileios.Kalintiris at imgtec.com> wrote:
> 
>> 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).

Sure. I’m not sure if everyone will agree with me, but my general assertion is that if you’re doing a full bootstrap of a cross compiler, we’re not going to fully support that from a single CMake build tree. We didn’t support that in autoconf, so I don’t think CMake should be different in that regard. I envision bootstrapping a full cross-platform to be something like:

(1) build in-tree clang
(2) build out-of-tree builtin library
(3) build out-of-tree runtime libraries

-Chris

> 
> - Vasileios