2

go build and go run are very slow on a tiny program I have (cgo invocations in particular). I'd like go to cache the binary so that it only rebuilds when the source is newer. I would use a simple Makefile with a % rule, but the language designers claim that go's build support doesn't need Makefiles.

Is there another alternative I've overlooked? Does the go community prefer another build system, maybe hash-based instead, for caching and reusing build products?

Tobu
  • 24,771
  • 4
  • 91
  • 98
  • 6
    `go install` and/or `go build -i`; they will install dependant packages that in future won't get rebuilt unless changed. A plain `go build` will rebuild changed dependant packages but won't save the results. – Dave C Aug 18 '15 at 00:40
  • 1
    This is exactly what `go install` is for. – JimB Aug 18 '15 at 00:51
  • `go build -x` tells me the time is spent rebuilding the tiny program. Dependencies are cached okay. – Tobu Aug 18 '15 at 03:41
  • `go install` with no arguments works, thank you! (but not `build -i`). At this point I was looking into `go list` formats, makedepends and continuous building. – Tobu Aug 18 '15 at 04:48
  • 1
    See this answer for [What does go build build?](http://stackoverflow.com/a/30612612/1705598) – icza Aug 18 '15 at 05:28

2 Answers2

7

go build and go install will soon (Go 1.10, Q1 2018) be much faster: see this thread and this draft document.

The go command now maintains a cache of built packages and other small metadata (CL 68116 and CL 75473). The cache defaults to the operating system-defined user cache directory but can be moved by setting $GOCACHE.
Run "go env GOCACHE" to see the current effective setting. Right now the go command never deletes anything from the cache. If the cache gets too big, run "go clean -cache" instead of deleting the directory. That command will preserve the cache's log.txt file. In a few weeks I'll ask people to post their log.txt files to a Github issue so that we can evaluate cache size management approaches.

The main effect of the build cache is that commands like "go test" and "go build" run fast and do incremental builds always, reusing past build steps as aggressively as possible.
You do not have to use "go test -i" or "go build -i" or "go install" just to get fast incremental builds. We will not have to teach new users those workarounds anymore. Everything will just be fast.

Note that go install won't installs dependencies of the named packages: see "What does go build build?".

Inanc Gumus
  • 25,195
  • 9
  • 85
  • 101
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

I wrote a tool that happens to solve this as a side effect. go build alone will not check if the executable it's producing is already up to date. go install does, and if you tweak it to install to a location of your choice, then you'll get the desired result, similar to go build.

You can see the behaviour you describe by doing something like this:

$ go get -d github.com/anacrolix/missinggo/cmd/nop
$ time go run "$GOPATH"/src/github.com/anacrolix/missinggo/cmd/nop/*.go

real    0m0.176s
user    0m0.142s
sys     0m0.048s

That's on a warm run. go run will link on every invocation, just as go build would. Note that github.com/anacrolix/missinggo/cmd/nop is an program that does absolutely nothing.

Here's invoking the same package, using my tool, godo:

$ time godo github.com/anacrolix/missinggo/cmd/nop

real    0m0.073s
user    0m0.029s
sys     0m0.033s

For larger programs, the difference should be more pronounced.

So in summary, your standard tooling option is to use go install, or an alternative like godo.

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526