Building with "go install" vs "go build"

[Jonathan Yu]

Hello Gophers!

There's a fair amount of documentation available[0] about how "go install" works, particularly in contrast to "go build,"[1,2] but not a lot about which one is more idiomatic/preferred.  Using the standard toolchain, it seems there's three ways to build your applications:

- go build

- go build -i

- go install

- Are there more that I'm unaware of? Are some preferred in certain circumstances (for example, "go install" for development, "go build" on CI or for building *.rpm and *.deb packages?)

Apparently Dave Cheney says to prefer "go install" over "go build"[3], except when cross-compiling [4]. However, many of these posts are older, and Golang moves at such a rapid clip that it's difficult to keep track of what everybody is doing.

Larger projects tend to use a bunch of shell scripts, so it can be difficult to tell what they're doing underneath, but I just did a quick survey:

Kubernetes[5] and OpenShift[6] use "go install" to build, and a cursory search of those repositories shows a healthy mix of both "go build" and "go install" amongst vendored libraries. Docker appears to use "go build"[7].

That Heartbleed/Ticketbleed guy with the great hair builds with "go test -i" if I'm reading the hellogopher code correctly[8].

Tim Hockin's boilerplate project uses "go install"[9].

Hopefully I didn't just accidentally start a flamewar/bikeshedding session with this question... Seems like an important thing to settle. I'm curious to hear your thoughts!

Cheers,

Jonathan

[0] https://golang.org/cmd/go/#hdr-Compile_and_install_packages_and_dependencies

[1] https://github.com/NanXiao/golang-101-hacks/blob/master/posts/go-build-vs-go-install.md

[2] https://www.quora.com/What-is-the-difference-between-build-and-install-in-Go

[3] https://peter.bourgon.org/go-best-practices-2016/#build-and-deploy

[4] https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5

[5] https://github.com/kubernetes/kubernetes/blob/3897fc00db947c5f782a8b9c68602339b16deeaa/hack/lib/golang.sh#L478-L481

[6] https://github.com/openshift/origin/blob/6d206d23bdf3654df3537ba034fa5bc7e5ad4697/hack/common.sh#L223-L228 (I think this was copied from k8s)

[7] https://github.com/docker/docker/blob/c07234707878412eaaeab252af19adac8cf25d6b/hack/make/.binary#L34-L42

[8] https://github.com/cloudflare/hellogopher/blob/master/Makefile#L33

[9] https://github.com/thockin/go-build-template/blob/43e119bda6199d80ecf6982b05b837e091aaeeba/build/build.sh#L37-L40

[Dmitri Shuralyov]

Are there more that I'm unaware of?

go get. It downloads source and follows it up with go install.

Are some preferred in certain circumstances

The three ways you listed are similar but not equivalent, they have subtle differences in behavior. Use whatever is a better fit for your needs. I use all of them depending on the situations.

Seems like an important thing to settle.

I'm not sure I understand what there is to settle.

[Dave Cheney]

> Apparently Dave Cheney says to prefer "go install" over "go build"[3], except when cross-compiling [4]. However, many of these posts are older, and Golang moves at such a rapid clip that it's difficult to keep track of what everybody is doing.

This information is still correct.

[Michael Jones]

The good news is that Dave Cheney moves at that same rapid clip.

:-)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones
michae...@gmail.com

[Marvin Renich]

* Dave Cheney <da...@cheney.net> [170418 09:57]:

> > Apparently Dave Cheney says to prefer "go install" over "go build"[3],
> except when cross-compiling [4]. However, many of these posts are older,
> and Golang moves at such a rapid clip that it's difficult to keep track of
> what everybody is doing.
>
> This information is still correct.
>
> On Friday, 10 February 2017 02:55:25 UTC+11, Jonathan Yu wrote:
> >
> > Hello Gophers!
> >
> > There's a fair amount of documentation available[0] about how "go install"
> > works, particularly in contrast to "go build,"[1,2] but not a lot about
> > which one is more idiomatic/preferred. Using the standard toolchain, it
> > seems there's three ways to build your applications:

I use "go build" in the "edit, build, test, repeat" cycle, and only use
go install when I have what I consider to be a working program. Often,
this involves incrementing the version and adding a version tag to the
repo.

If I used go install during edit-test, I would often have a non-working
executable in my path, so I would not be able to use the program for
"real" work while I am knee-deep in a bug fix or implementing a new
feature.

Dave's mileage obviously varies from mine, which is fine. However, I
believe my use case and reasoning is common enough that I believe it is
counterproductive to try to declare one way or the other to be "The
Idiomatic Way". This just boils down to personal preference and work
flow, and trying to tell others that one way is the "preferred" way is
wrong.

...Marvin

[Diego Medina]

> Often, this involves incrementing the version [...]

If the process of saying "this binary is good to go, deploy it locally for use" already involve more than go install, maybe you could also "deploy" the binary to a different location than $GOPATH/bin . The benefit there is that you can take advantage of the incremental/faster compile of go install, without having a broken binary.

Unless that has other negative side effects in your own setup. But, if you are ok with the speed of go build, no need to change.

[Dave Cheney]

To each their own, but please consider using the -v flag so you understand how many packages are bring recompiled each time. It is very common for a Go user to upgrade their Go version and find that compilation slowed down as the set of packages compiled each time now includes many long forgotten, once installed (via go get), packages that are now out of date.