Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: build should not change mtime on cache hit #24356

Closed
gaetmorin opened this issue Mar 12, 2018 · 3 comments
Closed

cmd/go: build should not change mtime on cache hit #24356

gaetmorin opened this issue Mar 12, 2018 · 3 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@gaetmorin
Copy link

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:

$ go build -o eg golang.org/x/tools/cmd/eg
$ stat eg

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 calling go build every time (a "phony" rule in Make terms). However, because the output mtime is modified at each invocation of go 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.

@mvdan
Copy link
Member

mvdan commented Mar 12, 2018

/cc @rsc

@mvdan mvdan added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 12, 2018
@mvdan mvdan added this to the Go1.11 milestone Mar 12, 2018
@odeke-em odeke-em changed the title go build should not change mtime on cache hit cmd/go: build should not change mtime on cache hit Mar 12, 2018
@rsc
Copy link
Contributor

rsc commented Mar 26, 2018

Not changing the mtime would break the isolation rule (see https://research.swtch.com/vgo-cmd). We set the mtime very explicitly, so that the result does not depend on prior state. There are tests explicitly for this case.

@dvyukov
Copy link
Member

dvyukov commented Apr 30, 2020

@gaetmorin have you found any workaround? I am trying to solve the same problem. So far no luck. Make rebuilds everything because of go build behavior :(

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

5 participants