Can't configure static differently for different platforms

[illicitonion]

What version of rules_go are you using?

0.31.0

What version of Bazel are you using?

5.1.0

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

macOS x86-64

Any other potentially useful information about your toolchain?

Using musl to cross-compile to Linux x86-64.

What did you do?

Trying to ensure that binaries built for Linux are statically linked, and for Darwin are not.

Writing code along the lines of:

go_binary(
    ...
    static = select({
        "@io_bazel_rules_go//go/platform:linux": "on",
        "//conditions:default": "auto",
    }),
)

What did you expect to see?

Expect this to lead to a static binary on Linux and a dynamic one on macOS.

What did you see instead?

A dynamic binary is produced on both platforms. This appears to be because of bazelbuild/bazel#15157 - this transition inspects attr.static to determine whether to statically link, but because the attribute is a configurable one, the transition doesn't see the value for the attribute at all, so defaults to "auto". It's explicitly not supported to consult configurable attributes in a transition (and should probably become an error), but it feels like being able to have platform-configurable static-ness is a pretty reasonable feature request.

It feels like there should be a way to do this attribute resolution which doesn't involve a transition, but I'm not familiar enough with the internals of rules_go to know what that would look like. Do folks have ideas for how we could make this static attribute stickier?

I'm happy to put in the work if folks have ideas for what this may look like...

[fmeum]

As bazelbuild/bazel#15157 only applies to incoming edge transitions, maybe the solution is to move rules_go's transitions to the relevant outgoing edges (e.g. deps)?

[illicitonion]

To make sure I understand, that means that rather than using go_transition_wrapper to conditionally generate a go_binary or go_transition_binary, we'd need to unconditionally generate a wrapper target which had an unconditional dep on a go_transition_binary, and that transition would be where the current go_transition_impl logic would have to happen?

[fmeum]

To make sure I understand, that means that rather than using go_transition_wrapper to conditionally generate a go_binary or go_transition_binary, we'd need to unconditionally generate a wrapper target which had an unconditional dep on a go_transition_binary, and that transition would be where the current go_transition_impl logic would have to happen?

I'm not intimately familiar with the internal rules_go setup, but I would have thought of the following: In go_binary, unconditionally set cfg on deps (and possibly the go_context if that's needed by the framework) to a transition that essentially does the same logic as the incoming transition on a go_transition_binary does today. Since the transition is now applied on an outgoing edge, it should be able to read the attributes of the go_binary just fine. This would also get rid of the transition wrapper, which shouldn't be needed: Transitions that do not cause any settings to change their values are true no-ops.

[fmeum]

Thinking a bit more about this: What would you expect to happen if the go_binary with a select on the platform also has goarch/goos set? I'm asking because the answer is most likely "evaluate the select based on the result of that platform change", but then that means we would like Bazel to resolve the select after some parts of an incoming transition have been applied.

[illicitonion]

What would you expect to happen if the go_binary with a select on the platform also has goarch/goos set?

I don't think it makes sense to have selects based on platform if you're hard-coding a platform.

As a concrete example, I don't think it makes sense to write:

go_binary(
    name = "bin",
    goos = "linux",
    goarch = "amd64",
    static = select({
        "@io_bazel_rules_go//go/platform:linux": "on",
        "//conditions:default": "off",
    }),
)

If you're hard-coding goos, it doesn't make sense to pretend that other attrs are dynamic.

Stepping back into the bigger picture, the goos and goarch attributes probably shouldn't actually exist; Bazel's platform support should be used instead, but it's currently not very ergonomic to do so and so they make sense for now. But I don't think we should give them much weight when considering other platform/toolchain-related features.

[fmeum]

Stepping back into the bigger picture, the goos and goarch attributes probably shouldn't actually exist; Bazel's platform support should be used instead, but it's currently not very ergonomic to do so and so they make sense for now. But I don't think we should give them much weight when considering other platform/toolchain-related features.

Fully agree here. I was just asking a "provocative" question so that we can pin down the intended semantics. goos and goarch should not be factored in there as they should become redundant as platform support matures.