cmd/go: build should not change mtime on cache hit #24356
Labels
FrozenDueToAge
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
What version of Go are you using (
go version
)?go version go1.10 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOCACHE="/home/gmorin/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/gmorin/src/go"
GORACE=""
GOROOT="/toolchain/linux64/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/toolchain/linux64/go-1.10/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build775565042=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Build a command with "go build" or "go install", then look at the file modification timestamp of the resulting binary. For example:
Repeat the operation immediately, without changing the source code.
What did you expect to see?
I would expect the timestamps to be identical in both builds.
What did you see instead?
The timestamps are different between the first and second build.
Some context:
This would simplify the use of the go command from build tools that read mtimes to detect staleness, such as Make.
Since Go 1.10, it is considerably easier to integrate the go command into larger build systems based on Make. Thank to the build cache,
go build -o
is fast and it is no longer necessary to go through $GOPATH/pkg and $GOPATH/bin. It is tempting to avoid any hacky staleness detection implemented makefiles and instead rely on the (more correct) detection done by the go command. That amounts to callinggo build
every time (a "phony" rule in Make terms). However, because the output mtime is modified at each invocation ofgo build
, rules depending on the build output trigger, and the build system does more work than necessary.I understand that there shouldn't be any hard guarantee on exactly when the timestamps are changed and how. However, it seems to me that the output of a non-stale build should be unchanged, at least most of the times.
Thank you for your time.
The text was updated successfully, but these errors were encountered: