[swift-dev] Cross-compiling with Toolchain files

[Tom Birch]

I agree that CMake really doesn't like building multiple target variants
within a single invocation, which is why I suggested Toolchain files in the
first place.  I don't follow your argument that wrapping ld, ar, ranlib,
etc. is preferable to using Toolchain files. The problem is that I'd not
only need to wrap these commands, but also change all the CMake configure
logic, i.e. all the find_package calls, the CMAKE_SYSTEM_NAME tests, and
the check_* calls (luckily there's only one check_symbol_exists call), and
I'm not sure what advantages this has over doing it "the CMake way". Is the
parallelism and the ability to use ninja to rebuild everything without
re-invoking CMake really worth all this extra effort? See
http://thread.gmane.org/gmane.comp.lang.swift.devel/911 for more details.

Just to be clear, are you suggesting building everything (OSX swiftc, OSX
stdlib, Linux stdlib) within a single CMake invocation? Dmitri explained
the reasoning behind doing this for Darwin-based targets (i.e. parallelism,
fast iteration without re-invoking CMake) , but as mentioned above, I don't
think this works well when mixing different toolchains (elf, mach-o) or
headers/libraries (e.g. Linux vs FreeBSD), as you end up having to
re-implement a lot of the CMake configure logic either in shell scripts or
CMake itself. If multiple CMake invocations are ok, why the aversion to
toolchain files?

cheers,
Tom

On Tue, Feb 16, 2016 at 10:57 PM Jordan Rose <jordan_rose at apple.com> wrote:

> 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 *build* machine is where you build the
> compiler, the *host* machine is where you run the compiler, and the
> *target* machine is where you run the code that comes out of the compiler.
>
> 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 *really* 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.
>
> 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.
>
> 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 support for cross-compilation
> <http://clang.llvm.org/docs/CrossCompilation.html#toolchain-options> (and
> CMake should be using Clang to link, I think?) so you should have a chance.
>
> Jordan
>
>
> On Feb 16, 2016, at 13:48 , Tom Birch via swift-dev <swift-dev at swift.org>
> wrote:
>
> 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:
>
>
> https://github.com/froody/swift/commit/bc7ca07c1c7a94a8d07acd635c486388640ee2d2
>
> Steps to repro are in cmake/modules/Toolchain-linux-arm.cmake
>
> 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
> https://bugs.swift.org/browse/SR-237 first/in parallel?
>
> I also required a change to LLVM:
>
> *https://github.com/froody/swift-llvm/commit/ed54c92943444999f11918f013cca1dba7892da1
> <https://github.com/froody/swift-llvm/commit/ed54c92943444999f11918f013cca1dba7892da1>*
>
> to fix this error:
>
> CMake Error: The inter-target dependency graph contains the following
> strongly connected component (cycle):
>   "NativeLLVMConfig" of type UTILITY
>     depends on "llvm-config" (strong)
>   "llvm-config" of type EXECUTABLE
>     depends on "NativeLLVMConfig" (strong)
>
> 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.
>
> Anyway, I'd appreciate any feedback on the direction/next steps.
>
> cheers,
> Tom
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160218/9f77d2e7/attachment.html>