cmd/go: go build ./... may or may not write executable to disk depending how many packages the import path pattern matches

[xyzst]

What version of Go are you using (go version)?

$ go version
go version go1.14.3 darwin/amd64

Does this issue reproduce with the latest release?

Issue is reproduced with the latest release.

What operating system and processor architecture are you using (go env)?

OS: macOS Catalina (10.15.5)

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/cest-la-vie/Library/Caches/go-build"
GOENV="/Users/cest-la-vie/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cest-la-vie/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/cest-la-vie/fsociety/dev/go/go-build-issue/L1/M0/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/qc/_15tg89d2xg2blsddq6f9zkc0000gn/T/go-build913708293=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I am trying to build a go module using go build ./... in the same directory as go.mod. It works fine when there's only a single go package (main) and file. But adding another package and file, referencing those functions in main, and executing the aforementioned command does not generate the executable.

I have a very basic go project that reproduces this issue (includes instructions): https://github.com/xyzst/go-build-bug

What did you expect to see?

An executable should be generated in the same directory as go.mod

What did you see instead?

The binary is not generated and I am not able to locate it anywhere.

There are workarounds available:

• go install ./... still works as intended and the binary is found in the expected location at $GOPATH/bin
• go build ./path/to/go/file/with/mainpkg.go will generate the binary as expected

[dmitshur]

This go build behavior is very old (and in my opinion unfortunate, but I don't know if it's viable to improve). It's a consequence of go build changing behavior depending on whether its given a single command or many packages. This is documented at https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies:

When compiling a single main package, build writes the resulting executable to an output file named after the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when writing a Windows executable.

When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.

The reason I think it's unfortunate is that when you use it with an import path pattern, the outcome (whether it writes something to the current working directory or not) might be hard to predict without knowing how many packages the import path pattern will match.

I'll let people more familiar with cmd/go see if there's already another issue tracking this (I looked here briefly and didn't spot one), and if anything more can or should be done.

/cc @jayconrod @bcmills @matloob

[bcmills]

As of Go 1.13, you can pass -o . to explicitly request output of multiple binaries (see https://golang.org/doc/go1.13#go-command, and design discussion on #14295).

For the sake of consistency, it is unfortunate that we do write the binary when the pattern happens to match only one package, but I'm not sure how feasible that would be to change.

[seankhliao]

given the presence of -o, I don't think we'll make any other change.