Hello Xavier,
You mean as part of the Android plugin? From: Xavier Ducrohet [mailto:x...@google.com] Sent: Wednesday, August 13, 2014 7:56 PM To: dev@gradle.codehaus.org Subject: Re: [gradle-dev] Android NDK support for nativeBinaries Hi Michael We are actually already working on a new NDK integration using the new c/cpp gradle plugin. It's a work in progress, but there's already code in our tree. On Wed, Aug 13, 2014 at 5:53 AM, Michael Putters <michael.putt...@binarygenetics.com <mailto:michael.putt...@binarygenetics.com> > wrote: Hello, With the new Android NDK bringing support for 64-bit ARM CPUs, I thought it would be a good time to add Android NDK support to Gradle's cpp subproject (with iOS following a bit further down the line). However before diving in, I have some questions regarding - among other things - the DSL and how the nice folks at Gradleware (especially Daz) want things done: 1. Toolchain 1.a. The Android NDK provides gcc and clang toolchains (for multiple architectures), so it makes sense to re-use the existing gcc code. While I worked a bit on the VisualCppToolchain detection code, I'm not quite sure how the gcc detection works at this point, but would it be ok to have a simple mechanism checking if the ANDROID_NDK environment variable is present and use that as a basis to detect available toolchains? 1.b. If the ANDROID_NDK variable is not available, the following could be used: model { toolChains { gcc(Gcc) { target('android') { path 'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin' } } } platform { android { architecture 'aarch64' operatingSystem 'android' } } } 1.c. The Android NDK toolchains have multiple packages, one for each target architecture. The compiler and its version can be detected from the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang 3.4 for the 64-bit ARM architecture), but does it mean I should a single toolchain (or at least one for gcc and one for clang) and an addPlatformConfiguration per supported architecture? Would that be an issue if we want to be able to do linux and android builds side by side? 2. Manifest 2.a. Android applications have an AndroidManifest.xml file that declares various information about the application, including its version and minimum/target operating system requirements. I'm assuming we should look for this file in /src/main/AndroidManifest.xml like they expect for the Android plugin? 2.b. It would be nice to be able to inject the minimum/target SDK level and the application version in the AndroidManifest.xml file before building, by copying the manifest to a temporary location modifying it there. But what would be the best way to specify the SDK level in the DSL? The Android plugin uses an android { } block, but I was thinking with the current DSL the easiest would be something like (pseudo-ish-code): platforms { android {} } binaries.all { if (platform == targetPlatforms.android) { manifest.minSdkVersion = 9 manifest.targetSdkVersion = 18 } } The manifest DSL object could also be used for Windows applications to embed a manifest in the resources. I guess the (global and less complex?) alternative would be adding it to the platform itself... 3. Resources 3.a. Should resources go in /src/main/res as the Android plugin expects, or in /src/main/rc like the windows resource plugin expects? At the moment I'm using /src/main/rc for both windows and linux (using objcopy on linux to do something similar to what rc.exe does). Technically, the Windows-ish /src/main/rc is closer to Android's assets (which are just abstract binary files) and Android's resources (which are images/xml/etc in directories with a particular naming convention). That's about it for now, this should be enough to get me started... BR, Michael --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
