I've done some investigation since posting. It seems the standalone native
plugin is a little confused about how gradle platforms and toolchain
targets work:
// All we care is the name of the platform. It doesn't matter what the
// architecture is, but it must be set to non-x86 so that it does not match
// the default supported platform.
platform.architecture("ppc");
platform.operatingSystem("linux");
If you specify the architecture correctly and set the operating system to
"android" then everything would work out fine since, unless you're running
gradle on android, you will never match the current operating system.
I'm working on a plugin that simply uses the NdkHandler and supporting
classes (e.g. StlConfiguration, etc.) to configure platforms and a
toolchain that builds for such platforms. Unfortunately, when you specify
source set dependencies, the android gradle plugin will only look in the
artifacts container on a project so linking at the component level does not
work. The workaround is probably just to manually specify your component as
an artifact of the project.
On Wednesday, March 9, 2016 at 9:57:00 AM UTC-8, dcow wrote:
>
> When cross compiling a component you need to compile for multiple
> platforms, not just one. For example, a platform is 'android' or 'osx'
> (system headers) and the desired target architecture such as 'x86' or
> 'arm'. But, the native plugin lists platforms as:
>
> [platform 'arm64-v8a', platform 'armeabi', platform 'armeabi-v7a',
> platform 'mips', platform 'mips64', platform 'x86', platform 'x86_64']
>
> Let's say I want to compile my "module" for both android and osx. I'd need
> to add 'osx_x84-64' as a platform. Is there a reason the android native
> plugin does not prefix the platforms it adds? Since the plugin doesn't
> prefix platforms, it unnecessarily limits not just the component it
> creates, but also any other components in the current project that wish
> to build alongside an android component--such as tests--to be build for
> android. I don't see any reason this limitation exists. It makes it
> frustrating to work withing the native gradle model. Effectively applying
> the native plugin clobbers usage of the gradle native plugins.
>
> It would be nice if the native plugin simply added a list of toolchains
> and platforms and an android model object container for configuration
> (compileSdkVerion, stl, toolchain, etc). When I make a component I can
> specify that the component should build for the android_x86-64 platform.
> Or, there could be a rule for new components that adds appropriate
> platforms with respect to the abiFilters property (or all supported abis by
> default). You can already configure flavors and build types on binaries as
> needed.
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
