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

[Geordie Jay]

Hi Dimitri, thanks for the enlightening read. I'll keep those ideas in mind.

By "Linux native" do you mean compiling eg. Linux arm from Linux x86_64
with the current scheme, and only running multiple invocations when
compiling for mutually ABI-incompatible platforms (eg. osx->android)?

As it stands that exact scenario seems to build ok with the current method,
I "just" got stuck at the linking phase. I did have the impression I was
fighting the system the whole time though, and it was pretty hard to keep a
mental model of what was going on.

My concern is that maintaining the two different schemes will be even more
confusing than maintaining one convoluted single-invocation scheme. Would
like to hear some more opinions about this.

Geordie
Dmitri Gribenko <gribozavr at gmail.com> schrieb am Di., 19. Jan. 2016 um
01:47:

> On Mon, Jan 18, 2016 at 2:44 PM, Geordie Jay via swift-dev
> <swift-dev at swift.org> wrote:
> > I'm in discussions about this with some others over at
> > https://github.com/SwiftAndroid/swift/issues/13
> >
> > Basically the Swift build process as is isn't made for arbitrary
> > cross-compiling. The iOS cross-compiling from OSX relies on some happy
> > accidents, e.g. that they're all Apple platforms, and isn't robust. So
> we're
> > discussing some alternatives that would eventually also benefit your
> porting
> > effort.
>
> Unfortunately CMake only supports one C compiler and one linker in one
> CMake invocation.  The "CMake way" for cross-compilation is to invoke
> CMake once for every part of the build that requires a different set
> of tools.  Thus, for Swift, we would need to invoke CMake once for
> building the tools running on the host (the swiftc running on OS X)
> with the host toolchain (clang from Xcode), and once for the Android
> target with the Android toolchain and the just-built Swift to build
> the standard library.
>
> The disadvantage to this approach is that there are many CMake
> invocations, and many ninja invocations.  This is bad for the same
> reasons why recursive make is bad. [1]  So we would like to keep the
> current scheme for as many targets as possible (OS X native, OS X to
> iOS cross-compilation, Linux native etc.), and use the multi-CMake
> scheme only where strictly required.
>
> [1] http://aegis.sourceforge.net/auug97.pdf
>
> 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>*/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160119/f4102b32/attachment.html>