Hi Dimitri, thanks for the enlightening read. I&#39;ll keep those ideas in mind.<br><br>By &quot;Linux native&quot; 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-&gt;android)?<br><br>As it stands that exact scenario seems to build ok with the current method, I &quot;just&quot; 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.<br><br>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.<br><br>Geordie<br><div class="gmail_quote"><div dir="ltr">Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>&gt; schrieb am Di., 19. Jan. 2016 um 01:47:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 18, 2016 at 2:44 PM, Geordie Jay via swift-dev<br>
&lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:<br>
&gt; I&#39;m in discussions about this with some others over at<br>
&gt; <a href="https://github.com/SwiftAndroid/swift/issues/13" rel="noreferrer" target="_blank">https://github.com/SwiftAndroid/swift/issues/13</a><br>
&gt;<br>
&gt; Basically the Swift build process as is isn&#39;t made for arbitrary<br>
&gt; cross-compiling. The iOS cross-compiling from OSX relies on some happy<br>
&gt; accidents, e.g. that they&#39;re all Apple platforms, and isn&#39;t robust. So we&#39;re<br>
&gt; discussing some alternatives that would eventually also benefit your porting<br>
&gt; effort.<br>
<br>
Unfortunately CMake only supports one C compiler and one linker in one<br>
CMake invocation.  The &quot;CMake way&quot; for cross-compilation is to invoke<br>
CMake once for every part of the build that requires a different set<br>
of tools.  Thus, for Swift, we would need to invoke CMake once for<br>
building the tools running on the host (the swiftc running on OS X)<br>
with the host toolchain (clang from Xcode), and once for the Android<br>
target with the Android toolchain and the just-built Swift to build<br>
the standard library.<br>
<br>
The disadvantage to this approach is that there are many CMake<br>
invocations, and many ninja invocations.  This is bad for the same<br>
reasons why recursive make is bad. [1]  So we would like to keep the<br>
current scheme for as many targets as possible (OS X native, OS X to<br>
iOS cross-compilation, Linux native etc.), and use the multi-CMake<br>
scheme only where strictly required.<br>
<br>
[1] <a href="http://aegis.sourceforge.net/auug97.pdf" rel="noreferrer" target="_blank">http://aegis.sourceforge.net/auug97.pdf</a><br>
<br>
Dmitri<br>
<br>
--<br>
main(i,j){for(i=2;;i++){for(j=2;j&lt;i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf(&quot;%d\n&quot;,i);}}} /*Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>&gt;*/<br>
</blockquote></div>