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

[Dmitri Gribenko]

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
compiler.

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
cross-compiling.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/