(cross-posted from r/golang
<https://www.reddit.com/r/golang/comments/9ssx4b/repeat_building_module_with_buildmodecshared/>
)
I've noticed a great improvement with caching when I build modules that
haven't changed. The execution of "go build" is quite fast, and it is nice
in a larger build script when I can always call the go build and just rely
on the go tool to know when it needs to rebuild.
But I have a particular target in a project that is built as a c-shared
library so that it can be used in a python library. The build command looks
like:
go build -o module.so -buildmode-c-shared domain.com/project/dep
But in this form, the go tool always goes through a bunch of expensive cgo
compiling even if nothing has changed. Is there any way around this to get
back to the cached behaviour of calling this without the buildmode flag? My
build system could be told about the source inputs in order to hash them,
but this is an external dependency that is in the "go.mod" and pulled by
the go tool. The only idea that partially works right now is if I have the
build system hash the go.sum, go.mod, and the vendor/
domain.com/project/dep/**. That works for both normal and
"replaced"-with-dev-location go.mod situations. But it wouldn't know to
rebuild again if it were using a module "replace" with the dev location and
a dependency outside of the tareget module changed (which obviously the go
compiler would know about). Maybe that is an acceptable edge case. But it
would be nice to know if the current caching behaviour is expected in the
go tool when using buildmode=c-shared?
Much appreciated!
Justin
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
