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? 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.
