On Fri, Jan 25, 2019 at 3:51 PM Tim Hockin <thoc...@google.com> wrote: > > I don't grok that reasoning - can you expand on it? Assume for a > second that it did NOT update mtime if the result did not change. I > can be confident that same mtime == no change, right? It doesn't > imply that different mtime == something change, but I think that's OK > (for my use, maybe I am limited in my imagination). Even > > Does it really matter if some corner cases result in spurious updates?
It would be nice if it worked that way, but I'm confident that if we avoided updating mtime when we knew the file did not change, and then later started updating mtime again, people would file bugs saying that the mtime was updated incorrectly. Right now we provide a simple API: run "go build" or "go install" and your executable will be up to date. Why do we need a more complex API? Let me turn it around: why do you care? For cases where you do care, could you instead keep a hash of the file contents? For what it's worth, you can fetch a hash of a Go program by running "go tool buildid PROGRAM". See https://golang.org/cmd/buildid. Ian > On Fri, Jan 25, 2019 at 3:02 PM Ian Lance Taylor <i...@golang.org> wrote: > > > > On Fri, Jan 25, 2019 at 1:07 PM 'Tim Hockin' via golang-nuts > > <golang-nuts@googlegroups.com> wrote: > > > > > > Example: > > > > > > ``` > > > $ which git-sync > > > > > > $ go install -installsuffix "static" ./cmd/git-sync/ > > > > > > $ ls -l --full-time `which git-sync`; md5sum `which git-sync` > > > -rwxr-xr-x 1 thockin primarygroup 13956902 2019-01-25 > > > 13:04:40.758632955 -0800 > > > /usr/local/google/home/thockin/src/go/bin/git-sync > > > 1200f479c8ba86f70f0e4a885ecdd5f2 > > > /usr/local/google/home/thockin/src/go/bin/git-sync > > > > > > $ go install -installsuffix "static" ./cmd/git-sync/ > > > > > > $ ls -l --full-time `which git-sync`; md5sum `which git-sync` > > > -rwxr-xr-x 1 thockin primarygroup 13956902 2019-01-25 > > > 13:04:53.817700697 -0800 > > > /usr/local/google/home/thockin/src/go/bin/git-sync > > > 1200f479c8ba86f70f0e4a885ecdd5f2 > > > /usr/local/google/home/thockin/src/go/bin/git-sync > > > ``` > > > > > > Is the desired behavior or just a side-effect? Is there any way to > > > defeat it? Would a patch for this be shot down? > > > > This is intended behavior. The comment in the code > > (https://golang.org/src/cmd/go/internal/work/exec.go) is > > > > // Whether we're smart enough to avoid a complete rebuild > > // depends on exactly what the staleness and rebuild algorithms > > // are, as well as potentially the state of the Go build cache. > > // We don't really want users to be able to infer (or worse start depending > > on) > > // those details from whether the modification time changes during > > // "go install", so do a best-effort update of the file times to make it > > // look like we rewrote a.Target even if we did not. Updating the mtime > > // may also help other mtime-based systems that depend on our > > // previous mtime updates that happened more often. > > // This is still not perfect - we ignore the error result, and if the file > > was > > // unwritable for some reason then pretending to have written it is also > > // confusing - but it's probably better than not doing the mtime update. > > // > > // But don't do that for the special case where building an executable > > // with -linkshared implicitly installs all its dependent libraries. > > // We want to hide that awful detail as much as possible, so don't > > // advertise it by touching the mtimes (usually the libraries are up > > // to date). > > > > Ian -- 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.
