There seems to be a growing number of flags required to get reproducible builds with Go (e.g. see #51748). It’d be nice if there was -reproducible flag that would
Disable CGO_ENABLED and GO_EXTLINK_ENABLED by default, unless explicitly set via environment variables.
Default to -reproducible=true for go install. Currently there are some platforms (e.g. android) where Cgo is required, but those are usually cross-compiled so CGO_ENABLED must be set explicitly anyway.
Forbid setting -buildvcs=auto explicitly—there is no reason to set that if the goal is reproducible builds.
Default to -trimpath=true and -buildvcs=true flags, unless explicitly set via command line arguments or GOFLAGS environment variable.
Additionally, for -reproducible=true and -buildvcs=true, given a non-dirty VCS source tree of an example.com module, go build -reproducible should produce the same output as go install example.com@version-or-revision (even if the current revision was not pushed yet). Otherwise, if the tree is dirty, build should fail.
If go.mod contains replace and other directives that would cause go install to fail, go build should fail too with -reproducible=true.
Using VCS information to make go build reproducible against go install seems to be non-trivial to implement, so alternatively perhaps we can just set -buildvcs=false by default with -reproducible flag.
The text was updated successfully, but these errors were encountered:
I think it could be confusing for a cmd/go flag like -reproducible to disable cgo. Many people want reproducible builds and many program use cgo. Having -reproducible disable cgo would be a confusing experience.
Setting up reproducible builds with C toolchain is already an explicit step since that relies heavily on the state of the host system (e.g. presence of the system libraries), and I don’t think an extra step of setting an environment variable would be confusing for people that need reproducible builds with Cgo. Also, currently Cgo must be enabled explicitly when cross-compiling.
That said, on a second thought, that would only cause an issue with go install that under this proposal would have -reproducible=true (and hence Cgo disabled), and I’d like to retract this part.
This way, builds that have to be reproducible can run with GOFLAGS=-reproducible without changing any existing behavior in Go toolchain when the flag is not set.
I don't really see a point in having a flag that can have every setting it controls then be overridden by something else, it makes it harder to reason about which setting is actually taking effect, especially combined with setting flags in GOFLAGS.
And having a flag named like this but only getting you half of the way there (if you use CGo) seems worse than having no such flag to mislead you.