[cfe-dev] [LLVMdev] [RFC] Ideas on improving Compiler-RT CMake

[Chris Bieneman]

[re-sending my response to Duncan because I didn’t hit reply-all :-)]

> On Jun 3, 2015, at 1:42 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> 
>> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com> wrote:
>> 
>> 
>>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>> 
>>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote:
>>>>> 
>>>>> 
>>>>>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at apple.com> wrote:
>>>>>> 
>>>>>>> If we drop support for building compiler-rt with GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library, after all.
>>>>>> 
>>>>>> 
>>>>>> I don’t know if it is on the table to drop supporting compiler-rt with GCC, but that would dramatically simplify things.
>>>>> 
>>>>> 
>>>>> Weird, I'd assumed building compiler-rt with something other than
>>>>> clang was unsupported.  Maybe I'm missing something, but shouldn't
>>>>> the only supported configuration be building with the just-built
>>>>> clang?
>>>> 
>>>> 
>>>> The current default for an in-tree build is to build compiler-rt with whatever compiler is being used to build Clang... sometimes that compiler is GCC.
>>>> 
>>>> I agree though. We should always use the just-built Clang, and have that behavior be opt-out (if folks need it), instead of opt-in as it is now.
>>> 
>>> What would the build system do for a cross compile of Clang?
>>> 
>> This is the big question right? If we decide to only support building compiler-rt with the just-built clang that inherently means that you always have to build a clang that can run on host, so cross-compiling clang means building for host first, then the target.
>> 
>> I don’t think that is the behavior we want.
> 
> Why not?

I don’t think you want to force anyone cross-compiling clang to also build a host clang for compiler-rt. If there were a good reason for it I could see it being a necessary evil, but I don’t think we have a technical reason for making this a requirement and doubling the time of a clang cross-build seems like a poor trade-off if we’re not getting something good in return.

> 
>> I suspect the behavior we probably want is to use the just-built clang by default unless you are cross-compiling, in which case use the host compiler.
> 
> This sounds reasonable (and would obviously be a big improvement), but
> I'm interested in what the arguments are against the above/below.
> 
> Another option that seems superficially reasonable to me:
> 
>  - Only support building compiler-RT with the "matching" clang.
>  - When cross-compiling clang, only support the same version of clang
>    as the host (and use the host compiler).  In other words, when
>    cross-compiling, only support a two-stage build, where the first
>    stage builds a host clang, and the second stage builds the cross
>    clang.
>  - When not cross-compiling, always use the just-built clang.

This is kinda what I was getting at with the end of my email.

We could possibly say compiler-rt can only be built with clang, and is only expected to work with clang (not as a libgcc replacement for gcc). And we could add an additional statement that if you are cross-compiling clang you must have a host clang that “matches” (for some definition of matches) the one you’re building.

-Chris

> 
>> Whether or not the host compiler needs to be clang, or any version restrictions we want to apply is a separate issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150604/4f74e102/attachment.html>