<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 4, 2015, at 6:18 PM, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" class="">vonosmas@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Sorry for the late response.</div><div class=""><br class=""></div><div class="">You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC build rules for Android are much simpler than for Darwin/Linux,</div><div class="">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</div><div class="">to eventually use for another platforms.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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:</div><div><br class=""></div><div><div> cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES=“armv7;armv7s;arm64"</div><div> -DCMAKE_TOOLCHAIN_FILE=<PATH_TO_LLVM>/cmake/platforms/iOS.cmake <path to source></div><div><br class=""></div><div>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.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Also check out LLVM_BUILD_EXTERNAL_COMPILER_RT flag, which is an attempt to use ExternalProject to recursively call CMake from LLVM/Clang</div><div class="">build tree. It doesn't iterate over all the target triples we want/can support, though. It had some problems with Ninja, though.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>I also think we can work around the Ninja issues by taking advantage of Ninja’s job pooling capabilities.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I'd also prefer to not move host==target to a special case, at least at the beginning.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>I definitely support the effort of simplifying things and generalizing the OS-specific code in CMake. Patches are more than welcome here =)<div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">We want to support building (at least part of) compiler-rt libraries with GCC. I'm mostly speaking about sanitizers here:</div><div class="">sanitizer runtimes shipped with GCC are built from the same sources we have in compiler-rt. However, I agree that it</div><div class="">should not be the default (just-built Clang should be the default) - we can just setup a buildbot that would build</div><div class="">standalone compiler-rt with GCC.</div></div></div></div></div></div></blockquote><div><br class=""></div><div>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).</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 4, 2015 at 3:45 PM, Reid Kleckner <span dir="ltr" class=""><<a href="mailto:rnk@google.com" target="_blank" class="">rnk@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Jun 4, 2015 at 3:02 PM, Chris Bieneman <span dir="ltr" class=""><<a href="mailto:beanz@apple.com" target="_blank" class="">beanz@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div></span><div class="">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. =/</div><div class=""><br class=""></div><div class="">Maybe if we use the standard cmake cross-compilation approach someone will come along later and solve this problem at the cmake level.</div></div></div></div>
<br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">Alexey Samsonov<br class=""><a href="mailto:vonosmas@gmail.com" target="_blank" class="">vonosmas@gmail.com</a></div></div>
</div>
</div></blockquote></div><br class=""></body></html>