<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The main reason we didn't even try to go for the CMake toolchain support is because of the old build/host/target problem. For those who don't know, in old GCC terminology, the <i class="">build</i> machine is where you build the compiler, the <i class="">host</i> machine is where you run the compiler, and the <i class="">target</i> machine is where you run the code that comes out of the compiler.</div><div class=""><br class=""></div><div class="">Right now our CMake project tries to build some binaries for the host machine (the compiler) and some binaries for the target machine (the runtime, standard library, and overlays). On non-Darwin platforms, these are always the same today; for us the host machine is OS X and we build several target standard libraries. CMake <i class="">really</i> doesn't like this, which is why a CMake-generated Xcode project still can't build for iOS, even though Xcode supports products with different platforms perfectly well.</div><div class=""><br class=""></div><div class="">So from CMake's perspective, we're always building for the host machine, and we pass some funny flags when building the runtime and stdlib. We get away with this because the OS X linker can also link binaries intended for iOS et al.</div><div class=""><br class=""></div><div class="">If you're planning on building a cross-compiler (build = OS X, host = OS X, target = Linux), I think you'd really have the best success by using the same mechanism we use to build multiple stdlibs on Darwin. You'd have to figure out how to trick it into using your linker for just those libraries, but Clang actually does have <a href="http://clang.llvm.org/docs/CrossCompilation.html#toolchain-options" class="">support for cross-compilation</a> (and CMake should be using Clang to link, I think?) so you should have a chance.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2016, at 13:48 , Tom Birch via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm working on cross-compiling swift using OS X to build a linux-arm runtime/stdlib, and I've had some success. My change is here:<div class=""><br class=""></div><div class=""><a href="https://github.com/froody/swift/commit/bc7ca07c1c7a94a8d07acd635c486388640ee2d2" class="">https://github.com/froody/swift/commit/bc7ca07c1c7a94a8d07acd635c486388640ee2d2</a><br class=""></div><div class=""><br class=""></div><div class="">Steps to repro are in cmake/modules/Toolchain-linux-arm.cmake</div><div class=""><br class=""></div><div class="">It's still a work in progress, but I wanted to get some feedback on whether or not I'm going in the right direction. Toolchain files are the recommended way for cross-compiling with CMake, but it seems like it doesn't mesh well with the current system of building multiple mach-o targets from a single CMake invocation (e.g. OS X, iOS, tvOS and watchOS built on OS X). I've also had to fight the build-system a lot (using many --skip-build-foo flags, and two invocations of ./utils/build-script) in order to avoid building ninja targets that don't exist, and I'm wondering if there's a better way to do this, i.e. to build llvm/clang/swiftc for OS X in llvm-macosx-x86_64/swift-macosx-x86_64 build directories, and use that to build (swiftc?)/stdlib/tests for linux-arm in a swift-linux-armv7 build directory. Maybe this is a good reason to do <a href="https://bugs.swift.org/browse/SR-237" class="">https://bugs.swift.org/browse/SR-237</a> first/in parallel?</div><div class=""><br class=""></div><div class="">I also required a change to LLVM:</div><div class=""><div class=""><br class=""></div><div class=""><font color="#3367d6" class=""><u class=""><a href="https://github.com/froody/swift-llvm/commit/ed54c92943444999f11918f013cca1dba7892da1" class="">https://github.com/froody/swift-llvm/commit/ed54c92943444999f11918f013cca1dba7892da1</a></u></font><br class=""></div></div><div class=""><br class=""></div><div class="">to fix this error:</div><div class=""> </div><div class=""><div class="">CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):</div><div class=""> "NativeLLVMConfig" of type UTILITY</div><div class=""> depends on "llvm-config" (strong)</div><div class=""> "llvm-config" of type EXECUTABLE</div><div class=""> depends on "NativeLLVMConfig" (strong)</div></div><div class=""><br class=""></div><div class="">Maybe Chris Bieneman has an idea about this? I seemed to successfully cross-compile with the "False AND" hack, not sure what's going on.<br class=""></div><div class=""><br class=""></div><div class="">Anyway, I'd appreciate any feedback on the direction/next steps.</div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Tom</div></div>
_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>