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

[Geordie Jay]

I'm still trying to grasp the fundamental difference in approaches here,
especially since you say there are multiple CMake runs already. More
importantly, I'd like to fully understand what's important to keep the
same, or at least its desired outcome, which I'm pretty sure is the (1)-(2)
cross-boundary dependency staying intact.

Is the difference that the cross-compilation dynamic targets in the current
paradigm are set up via CMake (rather than build-script)? Presumably this
leaves the the loop that builds the various targets "unrolled" and always
in CMake's output, instead of recreating the CMake files multiple times per
build-script run?

As to the workflow, what would stop devs from just having a global bash
alias to "check-swift" that invokes the build-script, achieving the same
effect?
Dmitri Gribenko <gribozavr at gmail.com> schrieb am Di., 19. Jan. 2016 um
12:09:

> On Tue, Jan 19, 2016 at 2:50 AM, Geordie Jay <geojay at gmail.com> wrote:
> > Ok I'm confused as to what you mean now. I can't imagine how it'd make
> sense
> > to run CMake multiple times to build from one host for its own platform
>
> To build a Swift distribution, we need to build two pieces: the Swift
> compiler and the standard library.
>
> When cross-compiling, you can build two different kinds of compilers:
> a compiler that runs on your host machine, or the compiler that runs
> on the target.
>
> To build the standard library, you need to use the Swift compiler that
> runs on the host and a Clang that runs on the host, but both
> configured to target your target platform.
>
> Thus, if you want to cross-compile to Linux arm from OS X, you would
> need to use two or three CMake invocations:
>
> (1) to build a Swift compiler that runs on OS X,
>
> (2) use (1) to build a standard library that runs on Linux arm,
>
> (3) build a Swift compiler that runs on Linux arm.
>
> There is a dependency edge between (1) and (2), but they are in
> different CMake invocations.
>
> When cross-compiling for iOS, tvOS and watchOS, there are many CMake
> invocations of the second kind -- in fact, multiple for every platform
> because of many slices.  And, even more, since those platforms use fat
> libraries, there needs to be a step that creates them from separate
> slices.
>
> 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.
>
> 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/7e5a6f57/attachment.html>