go/build: provide function to enumerate valid target combinations

[mcandre]

Please provide a reliable function to dynamically query the list of valid (GOOS, GOARCH) combinations, so that application maintainers can plug directly into this system and build as many ports as possible.

Certain workarounds have limitations:

• https://golang.org/doc/install/source#environment (out of date, requires HTML parsing, fragile)
• gox (out of date, requires shelling out)

This could all be streamlined with a first party API. An array of combination strings would be nice. Or a hashmap of valid combination strings, which could serve for both enumeration and efficient validation, acting logically as a mathematical set for existence / non-existence checks.

[cespare]

Use go tool dist list or go tool dist list -json.

[cespare]

(See context at #12270.)

Actually, I'll leave this open since you specifically asked for a Go API. But I think the answer will probably be to use go tool dist.

[mknyszek]

I'm not even sure which package this would go in, but I took a guess. Feel free to update the title if you have a better idea.

[mknyszek]

CC @rsc I guess?

[mcandre]

@cespare Yes, an API would be more efficient than a shell command.

I do appreciate the tip. I can use go tool dist list meanwhile as a workaround for a leaner mechanism.

I am planning on wrapping go tool dist list into a reusable tool for building as many ports as possible.

https://github.com/mcandre/factorio

Works similar to the venerable gox utility, but with simpler options. Mostly pass-through.

Now that the platform metadata comes dynamically from the real go command line tool, hopefully the data doesn't have to be manually updated as often. The intention is for the same factorio code to work with future Go releases, as the language continues to add (unanticipated) targets.

[mvdan]

I agree with @cespare that you want go tool dist list -json; I use it in my own "cross compile for release assets" script.

Getting the information from go tool dist feels right, because I'm going to call go build right after, so the list of targets is exactly right as it comes from the same source. If it came from go/build via a Go program, I would have to be very careful to use the same Go version in both:

1) building the program which imports go/build 2) running go build to use each target

Executing cmd/go does add a few milliseconds worth of overhead, but I'm not sure that that's more important than having to worry about the version skew - and offering the same information in two ways.