Enable transitive target CPU constraint

[steeve]

Hi,

As part of implementing c-archive and c-shared support, I'm trying to properly propagate CPU selection to the Go toolchain when doing things such as building an iOS app or library.
See https://github.com/znly/rules_go/commit/344d1337b0350ea5e3b9e712437d38f33054d8a7 and https://github.com/znly/rules_go/commit/fce5ac2d1f8a18ae77712cd392c76b54cb03e2d8.

I'm am quite confused as to how to do that properly based on constraints.

I am able to properly select based on a config_setting such as:

config_setting(
    name = 'ios_arm64',
    values = {"cpu": "ios_arm64"},
)

However, when trying to turn that into a constraint, in doing either:

constraint_setting(name = ":cpu")
constraint_value(
    name = 'ios_arm64',
    constraint_setting = ":cpu",
)

Or even:

constraint_value(
    name = 'ios_arm64',
    constraint_setting = "@bazel_tools//platforms:cpu",
)

And adding that constraints to the arch in list.bzl, it fails to properly select the correct target based on the ios_application I'm building, where config_setting works as expected.
I'm using the following command line

$ bazel build --ios_multi_cpus=arm64 //:sampleapp

This isn important because in the case of iOS one could have multiple versions of the c-archive built on different archs (armv7 and arm64).

Thanks!

[ianthehat]

ios_arm64 is not a cpu...
I am not entirely sure what you want to achieve, but we already have all the constraints for every goos and goarch declared, along with platform declarations for all valid combinations, and then config_setting declarations to match. You should not need to declare any new ones.

I have no idea if what you are trying to do will work though, I think you are after toolchain transitions, which we would love to have but are not exposed to skylark right now.

[steeve]

I'm trying to embed a go_binary built as c-archive as a dependency to a cc_library, which is then imported into a ios_application and have goos and goarch transitively selected based on ios_application architecture (or multi architecture, for that matter).

It does work fine when I specifically select the goos/goarch to match the ios_application's arch via platform (in this case darwin_arm64).

Note that selecting (source files, for instance) on config_setting ios_arm64 properly works when using ios_application, even though it's not specified on the command line.

Indeed toolchain transitions sounds quite a bit like what's needed. However, I'm surprised it properly works when using config_setting and not via constraints...

[steeve]

For future record, Bazel reports this:

ERROR: No default_toolchain found for cpu 'foo'. Valid cpus are: [
  darwin,
  darwin_x86_64,
  k8,
  ios_x86_64,
  ios_i386,
  ios_armv7,
  ios_arm64,
  watchos_i386,
  watchos_armv7k,
  tvos_x86_64,
  tvos_arm64,
  armeabi-v7a,
]

[ianthehat]

The cpu command line argument is not the same as the cpu constraint, the former is a hodgepodge of crazy values that only make sense to a CROSSTOOL (and the list varies depending on what crosstool is loaded), the latter has cpu and os correctly separated and is designed to work with toolchains and the constraint system (@bazel_tools//platforms:cpu and @bazel_tools//platforms:os)

I suspect the custom magic in the config transition logic for ios_application probably sets the effective value of the command line argument cpu for you, and thus selects based on that work, but they may have not got around to making the constraint system understand that transition, which would also mean that toolchain selection for anything you depend on would be broken. You would need to talk to the bazel team about that.

[steeve]

Very clear, thank you.
In this case, perhaps it would be possible to define the platform based on the config_setting?

That would be kind of a hack, but it might work.

[ianthehat]

We used to, but it was seriously problematic...

There was no sane way to map config setting to GOOS and GOARCH values, and many things allowed for go cross compile were not valid as --cpu values.
You could not control the config setting from skylark, so we could not cross compile except by setting --cpu on the command line.
There were at least three separate values for --cpu that meant windows on x86_64, the same was true for some other cases, so it was not possible to write sane select statements.
The set of values is entirely controlled by the CROSSTOOL, so any decision we made about mapping to GOOS and GOARCH was broken for anyone writing their own one.

I think there were some other issues, I don't remember fully any more.

Instead we describe a complete system based on constraints, and trust bazel to map the --cpu value to constraints correctly for now. Hopefully even that part will go away soon when the cc toolchain selection is switched to also obey constraints and the platform stuff stops being experimental.

What we need is for the thing that does the config transition for the ios rules to correctly set the constraints in the same way it would on start up when picking them based on --cpu, and make sure toolchain resolution is run in the dependent rules correctly.

[steeve]

Is there any way to define a constraint based on something else than internal Bazel state and platform?
In a nutshell I could detect the ios_arm64/ios_armv7 config_setting and manually set the goos/goarch constraints so that toolchain resolution works?

[steeve]

But actually, my only problem is because I'm trying to build a multi-arch artefact (namely an iOS app) and i'm not sure how to do that unless getting it via the cpu config_setting....

Apparently Bazel does propagate things such as target_gnu_system_name in the cpp fragment: https://github.com/znly/rules_go/commit/fce5ac2d1f8a18ae77712cd392c76b54cb03e2d8#diff-b1e7c11591fbac0890652d29a78d6222R55

Command line:

$ bazel build --ios_multi_cpus=armv7,arm64 //:sampleapp

[steeve]

Actually, I'm thinking i could hack it by selecting goos/goarch attrs in the go_binary rule maybe?

[ianthehat]

That might work, but it also might cause you issues with caching, depending on how the config switch for ios was written.
Another (ugly) way to do this is to declare multiple go_binary rules that force the goos and goarch attributes, and then a select statement that picks up the right one(s) from the ios rule. Do you use cgo at all (it makes a big difference, because the goos/goarch attributes can't affect the cc toolchain so using them is fraught with peril if you have cgo)
Whatever you do, it's not the correct long term solution, so don't invest too much in it :)

I am really interested to know what you are using go for on ios, I did not realize anyone was using that!

[steeve]

I am indeed using cgo!

Our app (Zenly) has a common "on-device app backend" that is built almost entirely using Go and GoMobile, for both Android and iOS. We've been doing this for a year and half now with great success, but are now kind of constrained by the fact that gomobile handles the build part (which was great for a long time) by itself, limiting us in the way we can mix and match languages and libraries (for instance, using a patched/modified Go runtime for golang/go#22716).

That part is responsible for network interface (via gRPC), talking to the device APIs directly (CoreLocation for instance, hence my issue about objc support and https://github.com/znly/rules_go/commit/a9a23fb08c4b35be72c488e3300d18447f173f1f) and pushing this data to the UI via ReactiveX endpoints. We use protobuf to do trans-vm marshalling and ReactiveX for concurrency unification between Java/Swift and Go, which nice features such as a ReactiveX subscription becoming a context.Context on the Go side. We plan to open source this eventually.

Also, finally being able to have one build tool for apps on both platforms, backend, protobuf while also properly expressing the dependency graph cross language is really, really cool (for instance part of the Swift app depending on part of the Go backend etc...).

Hence all the commits we are doing in our fork of rules_go :)

EDIT: and I should also point out that we are re-implementing what gomobile bind does, only with Bazel. We have a working prototype for iOS already (save for that issue :))

[steeve]

Bouncing on your comment, I just tested the following, on Bazel master:

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")

config_setting(
    name = "ios",
    values = {"cpu": "ios_arm64"},
    visibility = ["//visibility:public"],
)

go_library(
    name = "go_default_library",
    srcs = [
        "main.go",
    ],
    cgo = True,
    importpath = "github.com/znly/cmd",
    visibility = ["//visibility:private"],
)

go_binary(
    name = "cmd",
    embed = [":go_default_library"],
    goos = "darwin",
    goarch = select({
        ":ios": "arm64",
        "//conditions:default": "amd64",
    }),
    visibility = ["//visibility:public"],
)

And Bazel fails with:

$ bazel build //cmd:cmd --cpu=ios_arm64 -s
DEBUG: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/external/io_bazel_rules_go/go/private/common.bzl:170:5:
Current Bazel is not a release version, cannot check for compatibility.
DEBUG: /private/var/tmp/_bazel_steeve/e3cf18c019556143010ddd56b908ce94/external/io_bazel_rules_go/go/private/common.bzl:172:5: Make sure that you are running at least Bazel 0.8.0.
Unhandled exception thrown during build; message: Unrecoverable error while evaluating node 'PACKAGE:cmd' (requested by nodes '//cmd:cmd')
INFO: Elapsed time: 0.103s
FAILED: Build did NOT complete successfully (0 packages loaded)
    currently loading: cmd
java.lang.RuntimeException: Unrecoverable error while evaluating node 'PACKAGE:cmd' (requested by nodes '//cmd:cmd')
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:414)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:355)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: wrong type for attribute "goarch" in go_binary rule //cmd:cmd
	at com.google.devtools.build.lib.packages.AbstractAttributeMapper.get(AbstractAttributeMapper.java:70)
	at com.google.devtools.build.lib.packages.SkylarkDefinedAspect.lambda$getDefaultParametersExtractor$0(SkylarkDefinedAspect.java:190)
	at com.google.devtools.build.lib.packages.Attribute$SkylarkRuleAspect.getAspect(Attribute.java:131)
.....

[ianthehat]

I have been doing a lot of work to get to the point where the link modes will work properly, I see you are piggybacking of most of it.
I was focused on plugin (although I have hit a wall with compiling the standard library ready for that mode) but c-archive and c-shared are in the list of things I was planning to add, it may collide with your changes, if you let me know how you use them I can try to make sure we are compatible.

goarch has to be a plain string, because of the way it propagates onto an aspect.
My suggestion of using multiple go_binary rules and doing the select outside will still work (you could either do it on the ios rule or in a filegroup between the two)

[steeve]

What do you think I open a PR for link modes and have that conversation there?
There are tons of questions I would have loved to ask but I was just getting a hang of a Bazel itself so I thought I would investigate before.

I still have to rebase on the stdlib builder (not sure if it's really that big of a deal, though).

The more we upstream, the better.