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

[Alexey Samsonov]

Sorry for the late response.

You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC
build rules for Android are much simpler than for Darwin/Linux,
and assume that build tree will be properly configured to build a single
compiler-rt runtime for a specific triple. Probably this is the approach
you want
to eventually use for another platforms.

Also check out LLVM_BUILD_EXTERNAL_COMPILER_RT flag, which is an attempt to
use ExternalProject to recursively call CMake from LLVM/Clang
build tree. It doesn't iterate over all the target triples we want/can
support, though. It had some problems with Ninja, though.

I'd also prefer to not move host==target to a special case, at least at the
beginning.

I definitely support the effort of simplifying things and generalizing the
OS-specific code in CMake. Patches are more than welcome here =)

We want to support building (at least part of) compiler-rt libraries with
GCC. I'm mostly speaking about sanitizers here:
sanitizer runtimes shipped with GCC are built from the same sources we have
in compiler-rt. However, I agree that it
should not be the default (just-built Clang should be the default) - we can
just setup a buildbot that would build
standalone compiler-rt with GCC.



On Thu, Jun 4, 2015 at 3:45 PM, Reid Kleckner <rnk at google.com> wrote:

> On Thu, Jun 4, 2015 at 3:02 PM, Chris Bieneman <beanz at apple.com> wrote:
>>
>> One of my concerns is actually that the custom rules we have for the
>> sanitizer test suite doesn’t work at all on Darwin unless you have the OS
>> headers installed to / (which isn’t the default anymore). I think that
>> teaching CMake to be smart enough about how it invokes the compiler to be
>> able to support all our platforms will be a lot of work duplicating things
>> CMake itself already does.
>>
>
> Right, for problems like this, we'd end up writing lots of cmake code to
> go and find headers and libraries like this, effectively replacing the
> toolchain knowledge that we could get from cmake. It's a tradeoff that may
> or may not be worth it, and I'm not sure what the answer is. =/
>
> Maybe if we use the standard cmake cross-compilation approach someone will
> come along later and solve this problem at the cmake level.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/4ca1d971/attachment.html>