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.<br><br>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?<br><br>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?<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 12:09:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jan 19, 2016 at 2:50 AM, Geordie Jay <<a href="mailto:geojay@gmail.com" target="_blank">geojay@gmail.com</a>> wrote:<br>
> Ok I'm confused as to what you mean now. I can't imagine how it'd make sense<br>
> to run CMake multiple times to build from one host for its own platform<br>
<br>
To build a Swift distribution, we need to build two pieces: the Swift<br>
compiler and the standard library.<br>
<br>
When cross-compiling, you can build two different kinds of compilers:<br>
a compiler that runs on your host machine, or the compiler that runs<br>
on the target.<br>
<br>
To build the standard library, you need to use the Swift compiler that<br>
runs on the host and a Clang that runs on the host, but both<br>
configured to target your target platform.<br>
<br>
Thus, if you want to cross-compile to Linux arm from OS X, you would<br>
need to use two or three CMake invocations:<br>
<br>
(1) to build a Swift compiler that runs on OS X,<br>
<br>
(2) use (1) to build a standard library that runs on Linux arm,<br>
<br>
(3) build a Swift compiler that runs on Linux arm.<br>
<br>
There is a dependency edge between (1) and (2), but they are in<br>
different CMake invocations.<br>
<br>
When cross-compiling for iOS, tvOS and watchOS, there are many CMake<br>
invocations of the second kind -- in fact, multiple for every platform<br>
because of many slices. And, even more, since those platforms use fat<br>
libraries, there needs to be a step that creates them from separate<br>
slices.<br>
<br>
That's why I'm comparing this to "recursive make": if we use the CMake<br>
approach to cross-compiling with multiple CMake invocations, since we<br>
are building the compiler itself, we would be crating dependencies in<br>
the graph that CMake does not know about, and we would require some<br>
code to orchestrate the build. Just like recursive make does in its<br>
Makefiles.<br>
<br>
Using build-script to orchestrate this build would be a natural<br>
choice, but it would break many of the current workflows, where<br>
developers rely on quickly iterating in one build directory, invoking<br>
'ninja check-swift' directly to rebulid the compiler, all the<br>
downstream dependencies, and run tests.<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>