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

cmd/go: report an error for cmd (and std?) modules outside $GOROOT #33138

Open
gertcuykens opened this issue Jul 16, 2019 · 8 comments
Open

cmd/go: report an error for cmd (and std?) modules outside $GOROOT #33138

gertcuykens opened this issue Jul 16, 2019 · 8 comments
Labels
modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@gertcuykens
Copy link
Contributor

Trying to work on the src code of go doc but every time I try to compile a ./doc binary it uses other src code, it doesn't look in the current directory am in, I have to force it go build main.go

gert@gert ~/Desktop/go/src/cmd/doc:master> go build

gert@gert ~/Desktop/go/src/cmd/doc:master> ls
dirs.go         doc             doc_test.go     main.go         pkg.go          testdata

I can see a doc binary getting created but its not build form the main.go in current directory, I deliberately put a syntax error in main?

gert@gert ~/Desktop/go/src/cmd/doc:master> go build main.go 
# command-line-arguments
./main.go:78:2: syntax error: unexpected --, expecting }

details:

go version devel +f938b9b33b Wed Jun 26 20:26:48 2019 +0000 darwin/amd64

GOARCH="amd64"
GOBIN="/Users/gert/bin"
GOCACHE="/Users/gert/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/gert/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/gert/Desktop/go/src/cmd/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dv/8tlwvjr91zjdyq4rk14lkkfm0000gn/T/go-build645754300=/tmp/go-build -gno-record-gcc-switches -fno-common"

Workaround for me was match GOROOT with the repo as in, git clone everything in /usr/local/go and bootstrap using a /usr/local/go1 then I could work on go doc src code.

maybe related to #32724

@agnivade
Copy link
Contributor

Like @ianlancetaylor said in #32724, the current GOROOT and the toolchain's GOROOT are different. And it seems to always build the toolchain's GOROOT.

You can do go build -v -x to see that it is going to the go command's GOROOT and building the cmd/doc package from there.

cd /usr/local/go/src/cmd/doc
/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -std -complete -buildid lADuo9Si0DPa2yLChAN1/lADuo9Si0DPa2yLChAN1 -goversion go1.12.4 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./dirs.go ./main.go ./pkg.go

The solution is to use the tip compiler itself to build cmd/doc. Instead of go build, you can do ../../../bin/go build. Or just gotip build, where gotip is an alias to your tip binary.

@FiloSottile
Copy link
Contributor

While building the toolchain cmd/doc when running go build cmd/doc might be expected behavior, doing so when just running go build in a different package seems wrong.

(You should still use the matching toolchain because cmd/doc might not even build with older versions of Go.)

/cc @bcmills @jayconrod

@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 17, 2019
@FiloSottile FiloSottile added this to the Unplanned milestone Jul 17, 2019
@jayconrod
Copy link
Contributor

I believe this is working as intended. Packages paths within the standard library and the cmd module are resolved to specific directories within GOROOT. You can't declare a module named cmd outside of GOROOT.

It looks like you've checked out the Go repo to a directory separate from where the Go command is installed (GOROOT is /usr/local/go, but you're running in /Users/gert/Desktop/go). As others have said, build the toolchain with ./make.bash in src, then use that).

We should probably report an error for a module outside GOROOT named cmd.

@FiloSottile
Copy link
Contributor

We should probably report an error for a module outside GOROOT named cmd.

👍

@FiloSottile FiloSottile changed the title cmd/go: cmd/doc can only be build in $GOROOT cmd/go: report an error for cmd (and std?) modules outside $GOROOT Jul 17, 2019
@gertcuykens
Copy link
Contributor Author

gertcuykens commented Jul 17, 2019

It looks like you've checked out the Go repo to a directory separate from where the Go command is installed (GOROOT is /usr/local/go, but you're running in /Users/gert/Desktop/go). As others have said, build the toolchain with ./make.bash in src, then use that).

Yes but if you have manually set GOROOT env in .bashrc to /usr/local/go it still will pick that over /Users/gert/Desktop/go right, and the same would happen which ever go build you pick?

We should probably report an error for a module outside GOROOT named cmd.

👍

PS is cmd the only exception or are there other package names?

@jayconrod
Copy link
Contributor

std and cmd are the only special modules. I'm not sure what would happen if you create a std module somewhere else. All the packages in that module would probably have a std/ prefix in their paths. But this should probably be an error, too, to avoid confusion.

@bcmills
Copy link
Contributor

bcmills commented Jul 18, 2019

If you create a std module elsewhere, the packages within it do have the std prefix (and I'm pretty sure we have regression tests for that).

Working in an alternate std module is explicitly supported, although it's admittedly a bit weird. That was requested in #30756, which reported a regression from GOPATH mode.

@bcmills
Copy link
Contributor

bcmills commented Jul 18, 2019

Working in an alternate cmd module is a bit dicier, since (unlike std) the cmd module's path actually is a prefix of the package paths it contains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants