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
