llvm dev - Jun 2015 - [LLVMdev] [RFC] Ideas on improving Compiler-RT CMake

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?
>
> Jon
>
>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150602/09aee900/attachment.html>

> 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 <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.

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.

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

-Chris
> >
> > Jon
> >
> >
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>      
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> >>
> >
> > -- 
> > Jon Roelofs
> > jonathan at codesourcery.com <mailto:jonathan at
codesourcery.com>
> > CodeSourcery / Mentor Embedded
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150603/e61f7f23/attachment.html>

> 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 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.
> Whether or not the host compiler needs to be clang, or any version
restrictions we want to apply is a separate issue.