Apple & Android rules do not propagate the current platform

[steeve]

Description of the problem / feature request:

When using the Apple and Android tools, it seems the only way to detect the current target is via config_setting + cpu.
In my case this is unfortunate because I'm trying to reliably detect the proper toolchain to use for rules_go and thus let the constraints system do its thing.

Going config_setting is cumbersome because there is no way to do a single setting that could match ios_* cpu, for instance.

This is especially important for multi-arch builds.

Feature requests: what underlying problem are you trying to solve with this feature?

Properly detect the current target platform (os and arch), for instance:

• iOS, Android
• arm64, armv7

What operating system are you running Bazel on?

MacOS 10.13

What's the output of bazel info release?

bazel-bin: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/execroot/__main__/bazel-out/darwin-fastbuild/bin
bazel-genfiles: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/execroot/__main__/bazel-out/darwin-fastbuild/genfiles
bazel-testlogs: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/execroot/__main__/bazel-out/darwin-fastbuild/testlogs
character-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1
command_log: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/command.log
committed-heap-size: 779MB
execution_root: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/execroot/__main__
gc-count: 16
gc-time: 1014ms
install_base: /var/tmp/_bazel_steeve/install/e609d8da5ce5541ec935720649c2c81f
java-home: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre
java-runtime: Java(TM) SE Runtime Environment (build 1.8.0_151-b12) by Oracle Corporation
java-vm: Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) by Oracle Corporation
max-heap-size: 3817MB
message_log: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/message.log
output_base: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94
output_path: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/execroot/__main__/bazel-out
package_path: %workspace%
release: release 0.10.0-homebrew
server_pid: 14844
used-heap-size: 104MB

Have you found anything relevant by searching the web?

See #350 for reference.

Thanks!

[philwo]

@ulfjack Can you assign this to someone who knows about this? I'm not sure who would be the best fit.

[ulfjack]

I don't understand what you're asking, but I think you might want to use our cool new toolchain functionality, and not do it that way.

[katre]

If I am understanding the problem correctly, you have an iOS (or Android) app that depends on go_library (or go_binary?) targets, and the go targets are being built for the wrong CPU and architecture? This is unfortunate and may not be possible to fix until we manage to convert iOS (and/or Android) rules to use toolchains. Unfortunately, iOS moving to toolchains depends on finishing the C++ toolchains migration, and Android depends on Java toolchains (and probably also C++ for NDK stuff).

That said, if you have a reproducible case showing a specific error, I can take a look and see if there's a short-term workaround that helps get the Go targets built for the correct target platform.

[steeve]

@katre you are absolutely right.
Thank you for the fast responses. I just wanted to make sure there was an open issue about this.

To be clear for the other people who might read this: the rules_go selects its toolchain based on the platform constraints, but since iOS and Android rules do not make use of (or propagate) it, multi-arch builds don't select the right toolchain based on the current target system. This might also be the case for other platform based toolchains (Rust?, Haskell?).

At the moment, one can sort of work around it via config_setting + cpu (in the case of Apple, or crosstool for Android), but it doesn't really work for select tags that would match only on the OS (ie Darwin for iOS) since there is no real way to define multiple possible values for one config_setting (ie OR is not possible, AND is).

A perhaps short term workaround would be to be able to set/change the platform dynamically per rule, not only from the command line.

I managed to get around myself with make by extracting the artefacts from the sandbox and multiple bazel runs, one per platform.

I have opened a project at https://github.com/znly/rules_go_ios_example but the gist is at https://github.com/znly/rules_go/commit/c85f24a44fe2432df030917f37b87f1e4ea059be#diff-e890364c8387943bbd45d45210f7a169R35 and here https://github.com/znly/rules_go/commit/de22780b95b6222a3a0b65ee22688d5528c49bd7#diff-bc2a07279903454bf436c61369a3bd38R22

[steeve]

hi @katre, i'm seeing quite a bit of activity on the platforms and was wondering if the split configurations now properly propagate to the @target_platform now that aarch64, ios and android are declared there?

Although I saw some toolchains declaration, they seem to be dummy ones.

[katre]

Sadly, this is still not working properly. There's a lot of moving pieces, and the Apple/iOS rules sit on the top of the stack. The good news is that the C++ rules are mostly moved over to use toolchain resolution, which means next we can tackle the objc rules (and this should be simpler), and then the Apple/iOS rules themselves.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!