cmd/go: generate uses runtime values of GOARCH and GOOS instead of buildContext values

[nmiyake]

1. What version of Go are you using (go version)?
   go1.6.2
2. What operating system and processor architecture are you using (go env)?
   darwin/amd64
3. What did you do?

$ cat gen.go 
package test

//go:generate echo $GOOS
$ GOOS=linux go generate gen.go

1. What did you expect to see?
   linux
2. What did you see instead?
   darwin

---

This issue was raised as #11438 and fixed in Go 1.5, but the fix for #13124 caused a regression of this behavior in Go 1.6.

[adg]

A regression between 1.6 and 1.7, and should be easy to fix. Slating for 1.7.

[gopherbot]

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

[alexbrainman]

Before this change I could use go generate to generate $GOROOT\src\syscall\zsyscall_windows.go on my Linux computer. Not anymore:

# cd $GOROOT/src/syscall                                                 
# go version                                                             
go version devel +a1110c3 Tue Jul 12 19:18:08 2016 +0000 linux/386                   
# GOOS=windows go generate                                               
fork/exec /tmp/go-build001548608/command-line-arguments/_obj/exe/mksyscall_windows.exe: exec format error                                                                 
syscall_windows.go:17: running "go": exit status 1                                   
#                                                                        

What do you propose I do now? Thank you.

A regression between 1.6 and 1.7

This is not a regression from go1.6. I have no problem building $GOROOT\src\syscall\zsyscall_windows.go with go1.6.2.

I am not sure that new behavior is better? What was the original problem?

Alex

[ianlancetaylor]

@alexbrainman I think the fix for the program running go generate in the syscall package is to move the //go:generate comment from syscall_windows.go to syscall.go. The go generate command runs fine on any system; the only reason you are using GOOS=windows is so that go generate will look in syscall_windows.go.

I agree with the change in this issue--I think go generate should pass GOOS and GOARCH to the child process. Otherwise there is no simple way to get that information.

[alexbrainman]

I think the fix for the program running go generate in the syscall package is to move the //go:generate comment from syscall_windows.go to syscall.go

OK. Thank you.
#16368

Alex