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
This is using Go 1.6, but I don't think the behavior has changed recently.
go build (and probably other go commands) normally take Go package names (that is, relative to some GOPATH component) but, as special cases, also take relative and absolute directories.
go help packages says this:
An import path that is a rooted path or that begins with
a . or .. element is interpreted as a file system path and
denotes the package in that directory.
However, this does not fully describe the go tool's behavior when given relative paths such as . or ./hello. I haven't looked into the code, but it seems like the tool tries to resolve such paths relative to GOPATH and does different things depending on what it finds.
Here are two examples.
First, there is a very different error given depending on whether the given path is inside a GOPATH or not:
$ pwd
/tmp/build
$ ls
$ mkdir -p a/src b/src
$ cd a/src/
$ GOPATH=/asdf go build ./hello
can't load package: package ./hello: open /tmp/build/a/src/hello: no such file or directory
$ GOPATH=/tmp/build/a go build ./hello
can't load package: package hello: cannot find package "hello" in any of:
/home/caleb/apps/go/src/hello (from $GOROOT)
/tmp/build/a/src/hello (from $GOPATH)
There are actual behavior differences as well, though. For instance, you can build a package given a non-existent relative path if the resolved package name does exist in some other GOPATH component (or GOROOT, for that matter):
$ # continuing from above...
$ cd /tmp/build/b/src/
$ mkdir hello
$ cat > hello/hello.go
package main
func main() { println("hello") }
$ cd /tmp/build/a/src/
$ ls
$ GOPATH=/asdf go build ./hello
can't load package: package ./hello: open /tmp/build/a/src/hello: no such file or directory
$ GOPATH=/tmp/build/a:/tmp/build/b go build ./hello
$ ./hello
hello
That seems to directly contradict "interpreted as a file system path" in the go help packages output.
The text was updated successfully, but these errors were encountered:
This is using Go 1.6, but I don't think the behavior has changed recently.
go build
(and probably other go commands) normally take Go package names (that is, relative to some GOPATH component) but, as special cases, also take relative and absolute directories.go help packages
says this:However, this does not fully describe the go tool's behavior when given relative paths such as
.
or./hello
. I haven't looked into the code, but it seems like the tool tries to resolve such paths relative to GOPATH and does different things depending on what it finds.Here are two examples.
First, there is a very different error given depending on whether the given path is inside a GOPATH or not:
There are actual behavior differences as well, though. For instance, you can build a package given a non-existent relative path if the resolved package name does exist in some other GOPATH component (or GOROOT, for that matter):
That seems to directly contradict "interpreted as a file system path" in the
go help packages
output.The text was updated successfully, but these errors were encountered: