Gradle Native: always include targetplatform in build directories

Help/Discuss
1

Hi,

We currently have two native multi-project build environments. The first environment produces a number of native libraries (which can be for any of 3 target platforms). These libraries are compiled and then released preserving the output path.

The second environment produces a number of ‘test’ executables that link with previously compiled libraries using the pre-built library respository functionality.

We are attempting to template the pre-built library functionality in the test executable build scripts to minimise the work of setting up each library variant. With this we have come across an issue, we cant find the obvious solution to, regarding the default naming of output paths.

In particular, if a native library, in environment one, only targets a single platform the build path looks like:

build/binaries/debug/mybinary.lib

where as if it targets multiple platforms it looks like:

build/binaries/platform1debug/mybinary.lib
build/binaries/platform2debug/mybinary.lib
build/binaries/platform3debug/mybinary.lib

This obviously results in a mismatch where we may try to reference the library such that:

staticLibraryFile = file("${ProjName}/build/binaries/${LibName}StaticLibrary/${targetPlatform.name}${buildType.name}/${LibName}.lib")

So finally a question: Is there a way to modify the output path for the native binaries such that they always include their target platform even if there is only one of them? Or is there a neater way to handle referencing “previously compiled by gradle” pre-built libraries.

Any help appreciated.

Thanks,
Shaun

2

Can you make the build just a multi-project build (vs using the prebuilt trick)?

There’s not a way to force it to always include the platform, but if you define an extra platform (even if you don’t use it), it’ll cause Gradle to insert the platform all the time. e.g., use a target platform for itanium solaris.

3

Hi Sterling,

Thanks for the quick response.

Unfortunately, due to diversity requirements of the project, the environment one libraries have to be developed and built separately from the second test and validate environment during a secondary phase of the project.

As it stands, during main development they are actually part of a single multi-project build, the intention, was to build environment one, capture it into a deliverable, which strips the source and build mechanisms. Convert the build.gradle files to encapsulate the “repositories” for that item and allow the test item to reference the prebuilt variant. However we have hit 2 stumbling blocks, the one mentioned in this thread and the second that a repository doesnt resolve between projects, as mentioned in this thread.

The fake target platform may work, however, it could also lead to confusion for the development teams, who may try target that build, think more thought may be required from us.

As a side note: We are running a custom compile of gradle (supporting an alternative set of tool chains, non gcc), could I modify the gradle to always include the platform, any pointers on the right area to review?

Thanks again,
Shaun

4

Quick follow up:

We have devised the following workaround for the naming issue; Modified NativeComponentRules.java to have a AddDimension method which is called when adding the platform only.

Regarding the referencing a repository from another project, we resolved this issue as our error, we had not defined all the target platforms available for the libs in the model.

Thanks for your help.
Shaun