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

Dmitri Gribenko gribozavr at gmail.com
Wed Jan 20 15:43:29 CST 2016

On Wed, Jan 20, 2016 at 1:21 PM, Tom Birch <froody at gmail.com> wrote:
> 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?

I'm proposing we do (1) for new cross-compilation targets (like OS X
to Linux, or Linux x86_64 to Linux arm), but keep the current scheme
for Darwin.

To keep existing workflows working, I would suggest that native builds
keep building the standard library in the same CMake invocation as the

Optionally, cross-compiling builds can unconditionally invoke the
CMake build tool recursively for cross-compilation targets after the
compiler is built, to erase the difference between native builds and


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-dev mailing list