[swift-dev] Cross-compile for Android armv7 from OSX

[Tom Birch]

On Tue, Jan 19, 2016 at 3:09 AM Dmitri Gribenko via swift-dev <
swift-dev at swift.org> wrote:

> That's why I'm comparing this to "recursive make": if we use the CMake
> approach to cross-compiling with multiple CMake invocations, since we
> are building the compiler itself, we would be crating dependencies in
> the graph that CMake does not know about, and we would require some
> code to orchestrate the build.  Just like recursive make does in its
> Makefiles.
>
> Using build-script to orchestrate this build would be a natural
> choice, but it would break many of the current workflows, where
> developers rely on quickly iterating in one build directory, invoking
> 'ninja check-swift' directly to rebulid the compiler, all the
> downstream dependencies, and run tests.
>

What do you propose then? As I understand it, there are roughly two options:

1) Split the build of swiftc and stdlib into two CMake invocations,
requiring a separate CMake configure step for each build type of the SDK.
2) Keep things as they are with a single CMake invocation, and wrap
invocations of the toolchain (either with custom CMake commands or shell
scripts) to call the right tool with the right flags for each build type of
the SDK.

I think (1) is more likely to result in a cleaner, more maintainable
buildsystem as more cross-compile targets are added, but as you mentioned,
may lead to longer build times and broken workflows. Maybe the dependencies
could be fixed by using ExternalProject_Add.

I think (2) will initially be easier, but will pollute the "leaf" CMake
functions/targets with target-specific details, as already seems to be
happening in AddSwift.cmake.

Is there another approach I'm not considering? What is more likely to be
accepted into apple/swift master?

cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160120/0cd70334/attachment.html>