You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
env | grep GOROOT confirms that an explicit value is set: GOROOT=/home/travis/.gimme/versions/go1.10.1.linux.amd64
go env confirms GOROOT="/home/travis/.gimme/versions/go1.10.1.linux.amd64"
unset GOROOT
go env still confirms GOROOT="/home/travis/.gimme/versions/go1.10.1.linux.amd64"
Install Go tip into $HOME/gotip
go version confirms go version devel +06b326054d Sat Jun 2 18:00:44 2018 +0000 linux/amd64
go env confirms GOROOT="/home/travis/gotip"
If I don't unset GOROOT above, GOROOT is then the wrong value for my custom Go installation.
Clearly the workaround is simple, but given then now-accepted behaviour of the go tool is that it can work out GOROOT for itself, setting GOROOT doesn't feel like the right thing to be doing (not least because it requires working around).
Thanks
The text was updated successfully, but these errors were encountered:
I can't find the issue/CL to confirm exactly when this happened, but gimme should not need to set GOROOT; the Go tools can work it out for themselves.
Indeed, setting it potentially, as it did in my case, messes with custom Go builds (noting our discussion in #143).
Take the following example:
https://travis-ci.org/myitcv/vgoimporter/builds/387668416
The sequence is:
1.x
to choose latest version of 1 series (noting discussion in 1.x doesn't select latest 1 major series version #149)env | grep GOROOT
confirms that an explicit value is set:GOROOT=/home/travis/.gimme/versions/go1.10.1.linux.amd64
go env
confirmsGOROOT="/home/travis/.gimme/versions/go1.10.1.linux.amd64"
unset GOROOT
go env
still confirmsGOROOT="/home/travis/.gimme/versions/go1.10.1.linux.amd64"
$HOME/gotip
go version
confirmsgo version devel +06b326054d Sat Jun 2 18:00:44 2018 +0000 linux/amd64
go env
confirmsGOROOT="/home/travis/gotip"
If I don't
unset GOROOT
above,GOROOT
is then the wrong value for my custom Go installation.Clearly the workaround is simple, but given then now-accepted behaviour of the
go
tool is that it can work outGOROOT
for itself, settingGOROOT
doesn't feel like the right thing to be doing (not least because it requires working around).Thanks
The text was updated successfully, but these errors were encountered: