I have an enhancement to the Go backend that I’d like, but want to get feedback here before I start working on it. We have a need to build

go_binary

targets for multiple platforms, and right now it’s achievable through `environment`s primarily. But given how good Go’s cross-compliation support is, it seems odd to me that there’s (as far as I can tell) no native

pants

way to do that. What I’d propose is something similar to the

docker_image

target’s

build_platform

field, so you could do something like this for a Go target:

go_binary(
    name="bin"
    go_os=["linux"]
    go_arch=["amd64", "arm64"]
)

and end up with

bin_linux_amd64

and

bin_linux_arm64

in your

dist/

outputs. Thoughts? Is there already a clean way to do this that I’m missing?

I’m not familiar with the go backend, but that looks like feasible idea to me. I’d suggest perhaps considering using single values rather than list values for the fields though, unless

go

takes them as a single invocation to produce all outputs at once. That is, to preserve one target one compilation. You can then leverage parametrization to create all variants as needed, and you have the ability to interact with each specific target if needed.

Yeah that’s a good point, parameterize is the way to go

Agreed w/ Josh Andreas's recommendation to use

parametrize

. That fits with Pants's mental model really well: a target like

go_binary

corresponds 1:1 w/ a single binary artifact @fast-nail-55400 and I were two of the original authors of the Go backend. This change makes sense to me. I don't remember exactly, but suspect cross-compilation mostly wasn't implemented due to simple prioritization