[swift-dev] Cross-compile for Android armv7 from OSX

[Tom Birch]

Ok, thanks, I'll run with that. I
see SWIFT_NATIVE_(LLVM|CLANG|SWIFT)_TOOLS_PATH, is currently used/supported
anywhere? My current plan is to:
1) Build everything (llvm/clang, cmark, swift) for macosx-x86_64
2) Setup SWIFT_NATIVE_*_TOOLS_PATH to point to the respective dirs created
in (1)
3) Create a swift-android-armv7 build dir
4) Invoke CMake in swift-android-armv7 with vars from (2), plus a
Toolchain-android-armv7.cmake to set CMAKE_SYSTEM_NAME, CMAKE_SYSROOT, etc
for the android build

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 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?

cheers,
Tom

On Wed, Jan 20, 2016 at 1:43 PM Dmitri Gribenko <gribozavr at gmail.com> wrote:

> On Wed, Jan 20, 2016 at 1:21 PM, Tom Birch <froody at gmail.com> wrote:
> > On Tue, Jan 19, 2016 at 3:09 AM Dmitri Gribenko via swift-dev
> > <swift-dev at swift.org> wrote:
> >>
> >> That's why I'm comparing this to "recursive make": if we use the CMake
> >> approach to cross-compiling with multiple CMake invocations, since we
> >> are building the compiler itself, we would be crating dependencies in
> >> the graph that CMake does not know about, and we would require some
> >> code to orchestrate the build.  Just like recursive make does in its
> >> Makefiles.
> >>
> >> Using build-script to orchestrate this build would be a natural
> >> choice, but it would break many of the current workflows, where
> >> developers rely on quickly iterating in one build directory, invoking
> >> 'ninja check-swift' directly to rebulid the compiler, all the
> >> downstream dependencies, and run tests.
> >
> >
> > What do you propose then? As I understand it, there are roughly two
> options:
> >
> > 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.
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Is there another approach I'm not considering? What is more likely to be
> > accepted into apple/swift master?
>
> I'm proposing we do (1) for new cross-compilation targets (like OS X
> to Linux, or Linux x86_64 to Linux arm), but keep the current scheme
> for Darwin.
>
> To keep existing workflows working, I would suggest that native builds
> keep building the standard library in the same CMake invocation as the
> compiler.
>
> Optionally, cross-compiling builds can unconditionally invoke the
> CMake build tool recursively for cross-compilation targets after the
> compiler is built, to erase the difference between native builds and
> cross-compiling.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160121/5e9e1122/attachment.html>