caching of cgo compilation

[Alex Flint]

Under what conditions does a cgo package get recompiled? I am using go-sqlite3 and it appears that the C compiler/linker is run every time I build my project, even though I am not changing any of the C sources. I would have expected it to be run once and then the results re-used, but perhaps there are some special rules for cgo recompilation?

[Ian Lance Taylor]

Currently the go tool either compiles an entire package or doesn't
compile it at all. If it is a cgo package with .c files, it compiles
those .c files every time it thinks any part of the package needs to
be recompiled--e.g., if you changed the Go code.

I thought there was an issue open about that, but I couldn't find it.

Ian

[Dave Cheney]

If your cgo code is in another package to the one your are changing then compilation should be cached?

Are you using go build or go install?

[Alex Flint]

Hmm but I am also not changing the Go source of the package in question, yet the C sources seem to get recompiled.

Just to make sure we're on the same page, I have two packages: mypkg and go-sqlite3, where the former is pure Go and the depends on the latter, which contains both C and Go code. Whenever I make changes to Go sources in mypkg I can see that the cgo compiler is being run on go-sqlite3.

[John Weldon]

If you run `go install github.com/mattn/go-sqlite3/...` it'll cache that build step artifact.

John Weldon

m) 503-941-0825

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Cheney]

My guess is you are using go build, which compiles then discards everything it just compiled (unless what was compiled was a main package, in which case the binary will be left in your current working directory)

I recommend using go install -v rather than go build for general use.

[Hugh Emberson]

He might be running go test which also seems to rebuild everything every time unless it has been installed.

go test -i installs all the dependencies for a test and fixes this problem.

On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney <da...@cheney.net> wrote:

My guess is you are using go build, which compiles then discards everything it just compiled (unless what was compiled was a main package, in which case the binary will be left in your current working directory)

I recommend using go install -v rather than go build for general use.

[Dave Cheney]

This is why I recommend go install*

* There is only one place where go install is not appropriate, and
that is when cross compiling **

** when using version of Go distributed as a binary and installed in a
directory that you don't have permission to write to.

[Harmen B]

Or build with `go build -i`

[Dave Cheney]

I don't understand why that flag even exists, if feels like a symptomatic misfeature. Just use go install -v, always*

* except when cross compiling. 

[Rob Pike]

If you're testing a binary, go install will overwrite the installed version, which is usually not what you want. In that case, go build makes sense.

-rob