Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: let go generate pass through calling go binary #28250

Closed
SamWhited opened this issue Oct 17, 2018 · 6 comments
Closed

proposal: let go generate pass through calling go binary #28250

SamWhited opened this issue Oct 17, 2018 · 6 comments

Comments

@SamWhited
Copy link
Member

SamWhited commented Oct 17, 2018

I ran into an issue recently where I was using Go 1.11 features in an application but had Go 1.10 installed on the system. To build I was installing Go 1.11 via go get golang.org/dl/go1.11 && go1.11 download and then starting my build by calling go generate. My code generation also requires Go 1.11, but the go:generate line looks something like this:

//go:generate go run gen.go

However, this uses the version of Go on the system and the build fails because it needs to be using Go 1.11. I can't simply change this to go1.11 run gen.go because on other systems it's being built on (most of them, in fact) Go 1.11 is the default and I'm not downloading it from golang.org/dl.

To work around this, I've moved generation out into a script:

#!/bin/sh

/proc/$PPID/exe run gen.go 

and changed the generate line to invoke this:

//go:generate ./gen.sh

However, this only works if /proc is mounted which feels poor.
It would be nice if the Go binary that ran generate could be passed in for substitution, eg. maybe as $GO. This way the same binary could be invoked:

//go:generate $GO run gen.go
@gopherbot gopherbot added this to the Proposal milestone Oct 17, 2018
@gopherbot
Copy link

Change https://golang.org/cl/142887 mentions this issue: cmd/go/internal/generate: add Go bin path to env

@rsc
Copy link
Contributor

rsc commented Oct 17, 2018

Maybe instead we should put the effective GOROOT/bin at the head of the PATH during go generate invocation? Then all the existing files that say 'go run' work fine instead of needing to teach everyone to write $GO.

@rsc
Copy link
Contributor

rsc commented Oct 17, 2018

Note that we just rejected having a $GOCMD that go/packages would look at, for the same reason: we want $PATH to be the single way to control which go you run, instead of having two variables.

@jimmyfrasche
Copy link
Member

jimmyfrasche commented Oct 17, 2018 via email

@SamWhited
Copy link
Member Author

Maybe instead we should put the effective GOROOT/bin at the head of the PATH during go generate invocation? Then all the existing files that say 'go run' work fine instead of needing to teach everyone to write $GO.

This seems sane and would fix the issue I ran into with fewer changes on my part.

@SamWhited
Copy link
Member Author

Closing in favor of #28103

@golang golang locked and limited conversation to collaborators Oct 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants