<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jan 19, 2016 at 3:09 AM Dmitri Gribenko via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>What do you propose then? As I understand it, there are roughly two options:</div><div><br></div><div>1) Split the build of swiftc and stdlib into two CMake invocations, requiring a separate CMake configure step for each build type of the SDK.</div><div>2) Keep things as they are with a single CMake invocation, and wrap invocations of the toolchain (either with custom CMake commands or shell scripts) to call the right tool with the right flags for each build type of the SDK.</div><div><br></div><div>I think (1) is more likely to result in a cleaner, more maintainable buildsystem as more cross-compile targets are added, but as you mentioned, may lead to longer build times and broken workflows. Maybe the dependencies could be fixed by using ExternalProject_Add.<br><br>I think (2) will initially be easier, but will pollute the "leaf" CMake functions/targets with target-specific details, as already seems to be happening in AddSwift.cmake.</div><div><br></div><div>Is there another approach I'm not considering? What is more likely to be accepted into apple/swift master?</div><div><br></div><div>cheers,</div><div>Tom</div></div></div></div></div>