Fair point, of course. I care because Kubernetes and it's family of projects have Makefiles to encapsulate trickier aspects of building, including code generation. Compiling kubernetes takes a LONG time. It would be nice to avoid re-triggering secondary actions when the primary artifacts have not changed.
Could I checksum? Sure, but then I am writing a custom builder, so I might as well use Bazel (which has other issues). It's not a huge deal, today, but I really wanted to understand it. It just seemed broken. On Fri, Jan 25, 2019, 5:41 PM Ian Lance Taylor <i...@golang.org> wrote: > 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.
