CLI: explicit integration with cgo

[andrewrk]

This is just a proof-of-concept. Maybe it could be nice for Go
developers, but also maybe we don't put additional complexity into the
zig codebase when CLI flags work just fine.

See the discussion in #7342

[Vexu]

Suggested change

	if (std.mem.eql(u8, go_arch, "386")) {
	cpu_arch = null;
	if (std.mem.eql(u8, go_arch, "native")) {
	cpu_arch = null;

[lu4p]

I think this would be great, to onboard members of the go community to the zig project.

[lu4p]

I think this is an ok default behaviour, but this should be configurable via a flag or env var.

[LemonBoy]

I don't think that writing a shell script to perform the argument translation is that hard.
On the other hand maintaining this set of extra switches and making sure they don't regress is much harder.

[komuw]

https://go-review.googlesource.com/c/go/+/276412/ which is under review may fix this.

[jonjohnsonjr]

I don't think that writing a shell script to perform the argument translation is that hard.
On the other hand maintaining this set of extra switches and making sure they don't regress is much harder.

I tend to agree, though I don't personally want to be responsible for maintaining this mapping (and it seems silly to have everyone individually reimplement it), but it's not clear where something like that should live.

I'm not sure what the minimum bar is for creating a repository is under the ziglang org, but something like a github.com/ziglang/zig-cgo (or cgo-zig) that hosts the canonical translation layer would be a very nice thing to be able to reference. There seems to be precedent for this with docker-zig, zig.vim, vscode-zig, zig-mode, etc...

[andrewrk]

The more I think about it, the more I think there should not be a translation layer at all - typically when you are creating a cross build, you have in mind the target that you want to specify. You will then have the task of choosing a -target / -mcpu flags for Zig and GOOS/GOARCH env vars for go. It's possible that the target you want to give to Zig can't even be described by GOOS/GOARCH. For example OS version ranges, CPU features, dynamic linker path, C ABI, glibc version. In this case you must manually choose the Zig target configuration. So I think we may actually be doing a disservice by leading users to configure the much more detailed Zig target configuration via the coarse-grained go env vars.

Based on this, and @LemonBoy's point, I'm going to close this. I do, however, want to solve the problem of having zig choose a more effective local cache directory. (See golang/go#43078 (comment) for more details on that.)