Wrong transition from android_binary to cc_library, is this a bug?

173 views
Skip to first unread message

Johan Laine

unread,
May 4, 2021, 11:38:07 AM5/4/21
to bazel-discuss
Hello! We are trying to to build an android_binary that depends on a cc_library that is also built for other (non-android) platforms. 

When modifying this example to have a select statement in a cc_library, like

cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    copts = select({
        "@platforms//cpu:x86_64": ["This should not be selected for Android ARM"],
        "//conditions:default": [],
    }),
    deps = [":jni_dep"],
)
and running `bazel build //examples/android/java/bazel:hello_world` the x86_64 branch is erroneously selected.

According to the docs there should be a well-behaved transition from the android_binary to the cc_library, but I would expect that transition to not set "@platforms//cpu:x86_64" but rather some ARM cpu. If I inspect the output from `bazel config` for this target it looks like this:

FragmentOptions com.google.devtools.build.lib.analysis.PlatformOptions {
  experimental_add_exec_constraints_to_targets: []
  extra_execution_platforms: []
  extra_toolchains: []
  host_platform: null
  incompatible_auto_configure_host_platform: true
  incompatible_override_toolchain_transition: false
  incompatible_use_toolchain_resolution_for_java_rules: false
  platform_mappings: platforms/platform_mappings
  platforms: [@local_config_platform//:host]
  target_platform_fallback: @bazel_tools//platforms:target_platform
  toolchain_resolution_debug: false
  toolchain_resolution_override: []
}

I think that the issue here is that "platforms" is set to something that in turn sets the constraint_value "@platforms//cpu:x86_64". I would expect the value here to instead be some Android ARM or otherwise some null value.

I understand that android_rules is not ported to utilize the Platforms concept, but I have not found a way of using Platforms with select statements of this type. Are there any known workarounds?

Regards,
Johan

John Cater

unread,
May 4, 2021, 11:49:19 AM5/4/21
to Johan Laine, bazel-discuss
We are in progress migrating the android rules to use platforms, but the work isn't fully finished, and also isn't in a current release.

Instead of using a select on a constraint_value, instead you should currently select on the "--cpu" flag:

config_setting(
    name = "has_arm_cpu",
    values = { 'cpu': 'armeabi-7va'},
)

cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    copts = select({
        ":has_arm_cpu": [android-arm-specific flags],

        "//conditions:default": [],
    }),
    deps = [":jni_dep"],
)

That will work currently, and when we finish the work on Android rules we will publish migration steps, which will include updating selects like this.



--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/5c7bb3fa-8662-4b3c-b721-9d722fe9c44en%40googlegroups.com.

Johan Laine

unread,
May 5, 2021, 2:59:26 PM5/5/21
to bazel-discuss
Yes, selecting on "--cpu" or something else for ARM is fine, the problem is that we already have a lot cc_library targets that utilize the platforms repo defined constraint_values for linux/x86_64, as is recommended. And we can't get around needing to sometimes select on "@platforms//os:linux" or "@platforms//cpu:x86_64". So something like 

cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    copts = select({
        "@platforms//cpu:x86_64": [x86_64 specific flags],
        ":has_arm_cpu": [android-arm-specific flags],
        "//conditions:default": [],
    }),
    deps = [":jni_dep"],
)

doesn't work when being depended on from an android_binary. Due to the transition to "platforms: [@local_config_platform//:host]" both of the two first conditions will be true.

If there's no flag for controlling this behavior then I guess I should aim for a workaround, like not using @platforms and instead define my own "//platforms/cpu:x86_64"?

//Johan

John Cater

unread,
May 5, 2021, 4:12:50 PM5/5/21
to bazel-discuss
One option you could use would be to define a platform_mapping file (https://docs.bazel.build/versions/master/platforms-intro.html#platform-mappings) that will set the target platform based on your flags. This will allow you to define a mapping from the Android build flags you use to an Android-specific platform you define, and then the existing selects will work correctly, since the target platform will match your constraints.

The platform mapping has to be defined in the same workspace it is used, but the platform definition can be in the main workspace or in a repository you load from your WORKSPACE, whichever makes sense for your project.

John Cater

Reply all
Reply to author
Forward
0 new messages