<div dir="ltr">Ok, thanks, I'll run with that. <span style="line-height:1.5">I see SWIFT_NATIVE_(LLVM|CLANG|SWIFT)_TOOLS_PATH, is currently used/supported anywhere? My current plan is to:</span><div><div>1) Build everything (llvm/clang, cmark, swift) for macosx-x86_64<br>2) Setup <span style="line-height:1.5">SWIFT_NATIVE_*_TOOLS_PATH to point to the respective dirs created in (1)</span></div><div>3) Create a swift-android-armv7 build dir</div><div>4) Invoke CMake in <span style="line-height:1.5">swift-android-armv7</span><span style="line-height:1.5"> </span><span style="line-height:1.5">with vars from (2), plus a Toolchain-android-armv7.cmake to set CMAKE_SYSTEM_NAME, CMAKE_SYSROOT, etc for the android build</span></div><div><br></div><div>Ideally I'd only build the stdlib and tests for android, skipping the tools and and llvm/clang builds. Does this seem feasible? I know the runtime depends on llvm headers, but I can either use the <span style="line-height:1.5">macosx-x86_64 llvm headers, or do a partial headers-only install of llvm-android-armv7. Are there any binaries/tools needed to be built for the target (i.e android-armv7) in order to build stdlib? Anything else I should know/watch out for?</span></div></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">cheers,</span></div><div><span style="line-height:1.5">Tom</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 20, 2016 at 1:43 PM Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 20, 2016 at 1:21 PM, Tom Birch <<a href="mailto:froody@gmail.com" target="_blank">froody@gmail.com</a>> wrote:<br>
> On Tue, Jan 19, 2016 at 3:09 AM Dmitri Gribenko via swift-dev<br>
> <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<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>
><br>
> What do you propose then? As I understand it, there are roughly two options:<br>
><br>
> 1) Split the build of swiftc and stdlib into two CMake invocations,<br>
> requiring a separate CMake configure step for each build type of the SDK.<br>
> 2) Keep things as they are with a single CMake invocation, and wrap<br>
> invocations of the toolchain (either with custom CMake commands or shell<br>
> scripts) to call the right tool with the right flags for each build type of<br>
> the SDK.<br>
><br>
> I think (1) is more likely to result in a cleaner, more maintainable<br>
> buildsystem as more cross-compile targets are added, but as you mentioned,<br>
> may lead to longer build times and broken workflows. Maybe the dependencies<br>
> could be fixed by using ExternalProject_Add.<br>
><br>
> I think (2) will initially be easier, but will pollute the "leaf" CMake<br>
> functions/targets with target-specific details, as already seems to be<br>
> happening in AddSwift.cmake.<br>
><br>
> Is there another approach I'm not considering? What is more likely to be<br>
> accepted into apple/swift master?<br>
<br>
I'm proposing we do (1) for new cross-compilation targets (like OS X<br>
to Linux, or Linux x86_64 to Linux arm), but keep the current scheme<br>
for Darwin.<br>
<br>
To keep existing workflows working, I would suggest that native builds<br>
keep building the standard library in the same CMake invocation as the<br>
compiler.<br>
<br>
Optionally, cross-compiling builds can unconditionally invoke the<br>
CMake build tool recursively for cross-compilation targets after the<br>
compiler is built, to erase the difference between native builds and<br>
cross-compiling.<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>