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

[Alexey Samsonov]

On Fri, Jun 5, 2015 at 10:57 AM, Chris Bieneman <beanz at apple.com> wrote:

>
> On Jun 4, 2015, at 6:18 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
>
> 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.
>
>
> This is the basic idea. I don’t know that I’d say the Android toolchain is
> materially simpler than the iOS one. They do basically the same thing. The
> difference is that on OS X we have tools (xcrun and xcodebuild) that have
> the ability to find sysroots and toolchain tools. This results in the iOS
> toolchain running tools find the right paths to things, and thus supporting
> multiple versions of Xcode and the corresponding SDKs.
>
> The Android toolchain is more fragile. It relies on clang being found via
> a relative path, and requires the sysroot path be explicitly set as an
> input variable. While the Cmake file is technically less complex, using it
> is more complex. I can cross-compile LLVM for iOS using the relatively
> simple CMake command:
>
>  cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES=“armv7;armv7s;arm64"
>   -DCMAKE_TOOLCHAIN_FILE=<PATH_TO_LLVM>/cmake/platforms/iOS.cmake <path to
> source>
>
> I think that if we do this how I’m suggesting and base this all off a
> mapping of triples to toolchain files, we’ll want the Android toolchain
> file to get more complex so that it has less hard coded assumptions.
>
>
> 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.
>
>
> LLVM_BUILD_EXTERNAL_COMPILER_RT is basically the way I think we want to go
> forward, but there are some changes that need to be made to deal with
> toolchains and properly mapping targets.
>
> I also think we can work around the Ninja issues by taking advantage of
> Ninja’s job pooling capabilities.
>
>
> I'd also prefer to not move host==target to a special case, at least at
> the beginning.
>
>
> When I talked to Chandler about this last night, my impression was that he
> agreed with me that at least having the option to not treat compiler-rt
> built for host as an external project was important for iterative
> development.
>

Why? So that when you hack on Clang and run "make check-all" you won't
recompile all the compiler-rt? I'd say it's not a big deal, as we currently
use just-built Clang to recompile all
compiler-rt unit tests, and this compilation is slow and in general
comparable to the time you'd need to rebuild the runtimes as well.


> 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.
>
>
> It is good to know the sanitizers are used with GCC. I think the goal
> should be just-built clang is the default unless you are cross-compiling
> clang, in which case the compiler used to build clang is used (could be the
> system compiler or an override one).
>

Sure, we already have the option to build compiler-rt as a standalone CMake
project with any host compiler we like.

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


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