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

[Chris Bieneman]

Since nobody seems to disagree with the basic idea here I’ve sent out my first cleanup patch:

http://reviews.llvm.org/D10250 <http://reviews.llvm.org/D10250>

-Chris

> On Jun 4, 2015, at 11:32 AM, Chris Bieneman <beanz at apple.com> wrote:
> 
> [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 <mailto:dexonsmith at apple.com>> wrote:
>> 
>>> 
>>> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>>> 
>>> 
>>>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>>>> 
>>>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com <mailto: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 <mailto: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/llvm-dev/attachments/20150604/2a36b502/attachment.html>