I've wanted this too for the Go builders.

See also my comment on https://go-review.googlesource.com/#/c/14272/ where the map of GOOS/GOARCH pairs supporting cgo is duplicated.

That could move to this internal package.

/cc @minux

CL https://golang.org/cl/14278 mentions this issue.

Hmm, I don't think the CL satisfy me.

(not tested! sorry!)
Please consider platforms: "nacl_amd64", "linux_s390"

• Both of two are supported by go (build) command and go/build package.
• gccgo support "linux_390", but gc doesn't.
• gccgo and gc doesn't support "nacl_amd64".

My point is:

• Build contexts and compiler supported contexts are different concepts.
• Compiler supported contexts are part of build contexts.
• Compiler supported contexts are different per implementations.

Maybe there are wrong assumptions, if so, please feel free to correct me.

Thank you.

hiro

Where is plan9?

gccgo?

And note that gc can build for any target supported, but for gccgo you actually need to build and install a separate gccgo for any platform you need.

Hmm, is this mean gccgo isn't able to cross compile? or need to compile libgo per platforms?

Anyway, I think runtime package is an appropriate place to put compiler-dependent information.

What do you think?

Thank you.

hiro

Finally, I am convinced by your suggestion.

I still think cgoEnabled should be different per implementations in go/build package.
But it's a different issue.

I also suggest cmd/api should be updated after you reaching the goal.

func defaultContexts() []*build.Context {
  switch runtime.Compiler {
  case "gc":
    return xxx // import from go tool dist list
  case "gccgo":
    return yyy // do something
  } 
}

Thank you for your kindly responses.

hiro

CL https://golang.org/cl/18687 mentions this issue.

CL https://golang.org/cl/19837 mentions this issue.