cmd/go: install support -o flag

[leighmcculloch]

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

$ go version
go version go1.17.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/leighmcculloch/.local/bin"
GOCACHE="/Users/leighmcculloch/Library/Caches/go-build"
GOENV="/Users/leighmcculloch/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/leighmcculloch/.local/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/leighmcculloch/.local/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/leighmcculloch/.local/bin/go/latest"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/leighmcculloch/.local/bin/go/latest/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="0"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/q5/xb4dl4bs3cs32khlg0ryy0vw0000gp/T/go-build1564949535=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Tried to install delve to a different binary output than the default.

go install -o $GOBIN/dlv-dap github.com/go-delve/delve/cmd/dlv@master

What did you expect to see?

I expected to see go install respect the -o build flag that works with go build.

What did you see instead?

flag provided but not defined: -o

Discussion

On closer inspection I see there's a distinction that is counterintuitive. The go build command supports "build flags" and other flags, where -o is one of those other flags and not a "build flag" even though -o is a flag of the "build" command.

$ go help install
usage: go install [build flags] [packages]
...
For more about the build flags, see 'go help build'.

$ go help build
usage: go build [-o output] [build flags] [packages]
...
The -o flag forces build to write the resulting executable or object
to the named output file or directory, instead of the default behavior

Installing to other filenames would be convenient and useful for go install for the same reasons it is convenient and useful for go build. Sometimes the output file needs to be different. In my specific example I'm attempting to install delve in the same way that the vscode-go extension installs delve, with the master branch version of delve installed at $GOBIN/dlv-dap and the latest version installed at $GOBIN/dlv.

Of course, it is possible to install using go build manually in the longer form, and so this isn't a huge deal:

dir=$(mktemp -d)
pushd $dir
git clone https://github.com/go-delve/delve
pushd delve/cmd/dlv
go build -o $GOBIN/dlv-dap
popd
popd
rm -fr $dir

The fact -o works for build and not install is counterintuitive. -o would be convenient and useful in go install also.

Proposal template

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  Experienced

• What other languages do you have experience with?
  Java, Ruby, C#, C, JavaScript

• Would this change make Go easier or harder to learn, and why?
  A little easier because the term 'build flags' is easily understood to mean the flags of the build command.

• Has this idea, or one like it, been proposed before? If so, how does this proposal differ?
  Not that I could find.

• Who does this proposal help, and why?
  Anyone installing Go tools and wishing to choose the install filename

• What is the proposed change?
  See above.

  • Please describe as precisely as possible the change to the language.
    See above.

  • What would change in the language spec?
    None.

  • Please also describe the change informally, as in a class teaching Go.
    See above.

• Is this change backward compatible?
  Yes

  • Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.

• Show example code before and after the change.
  See above.

• What is the cost of this proposal? (Every language change has a cost).

  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    None.
  • What is the compile time cost?
    Insignificant.
  • What is the run time cost?
    Insignificant.

• Can you describe a possible implementation?
  Add a flag.

  • Do you have a prototype? (This is not required.)
    No. But I can take a stab at contributing it.

• How would the language spec change?
  It wouldn't.

• Orthogonality: how does this change interact or overlap with existing features?
  It makes the install command more consistent with the build command.

• Is the goal of this change a performance improvement?
  No.

  • If so, what quantifiable improvement should we expect?
  • How would we measure it?

• Does this affect error handling?
  No.

  • If so, how does this differ from previous error handling proposals?

• Is this about generics?
  No.

  • If so, how does this differ from the the current design draft and the previous generics proposals?

[leighmcculloch]

Of course, it is also possible to do other things with GOBIN to work around this limitation too, so as to still get the benefit of the go proxy and without needing vcs like git:

dir="$(mktemp -d)"
GOBIN="$dir" go install github.com/go-delve/delve/cmd/dlv@master
cp "$dir/dlv" "$GOBIN/dlv-dap"
rm -fr $dir

[seankhliao]

Duplicate of #44469