Hi Dimitri, thanks for the enlightening read. I'll keep those ideas in mind.<br><br>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)?<br><br>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.<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 <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> 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>
<<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
> I'm in discussions about this with some others over at<br>
> <a href="https://github.com/SwiftAndroid/swift/issues/13" rel="noreferrer" target="_blank">https://github.com/SwiftAndroid/swift/issues/13</a><br>
><br>
> Basically the Swift build process as is isn't made for arbitrary<br>
> cross-compiling. The iOS cross-compiling from OSX relies on some happy<br>
> accidents, e.g. that they're all Apple platforms, and isn't robust. So we're<br>
> discussing some alternatives that would eventually also benefit your porting<br>
> effort.<br>
<br>
Unfortunately CMake only supports one C compiler and one linker in one<br>
CMake invocation. The "CMake way" 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<i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/<br>
</blockquote></div>