PlatformAwareComponentSpec.targetPlatform doesn't behave according to documentation

not-a-bug

(Daniel Lacasse) #1

It was raised to my attention that the behavior stated in the documentation 72.16.4 (https://docs.gradle.org/current/userguide/native_software.html#N18E09) does reflect the reality for native development.

Considering the following build.gradle:

apply plugin: "c"
model {
  buildTypes {
    debug
    release
  }
  platforms {
    x86 {
      architecture "x86"
    }
    x64 {
      architecture "x64"
    }
  }
  components {
    main(NativeExecutableSpec)
  }
}

The task listing show:

$ ./gradlew.bat :tasks
...
mainDebugExecutable
mainReleaseExecutable
...

However, if we change the component definition to add targetPlatform specifically:

...
main(NativeExecutableSpec) {
  targetPlatform "x86"
  targetPlatform "x64"
}
...

The task listing is correct:

$ ./gradlew.bat :tasks
...
mainX64DebugExecutable
mainX64ReleaseExecutable
mainX86DebugExecutable
mainX86ReleaseExecutable
...

We should be expecting the later result with the first build.gradle configuration if the documentation is right. This was tested using Gradle 2.14.1


(Paul Merlin) #2

Hi Daniel,

You’re right, this is confusing.

The documentation says that as soon as you declare platforms they are all used as target platforms for all components except if you specify target platforms at the component level.

The actual behaviour is that as long as you don’t specify target platforms at the component level then only the “default current” one is used.

This changed in 2.3, see the breaking change section in the 2.3 release notes.
Looks like the documentation has not been updated since then, good catch!

I’ll update the docs.

Thanks!


(Daniel Lacasse) #3

Excellent thanks for the information. I will make sure my team is aware.


(Paul Merlin) #4

Here is the fix, please comment the commit if it is not clear enough.


(Daniel Lacasse) #5

Thanks Paul for the fix!

I commented the response I got from my developers on this fix. Hopefully, we can make the documentation clearer for Gradle users.


(Paul Merlin) #6

@Daniel_L, refined in 283b5b68b6a841e175390b308bb709dac4de1488


(Daniel Lacasse) #7

Thanks Paul! This works better. Thanks for the effort in clarifying this.