On Fri, Jan 25, 2019 at 11:43 PM Paul Jolly <p...@myitcv.io> wrote: > > Tim - in case it's of any interest, I am in the process of (re)writing > a dependency-aware wrapper around go generate that caches results in > an artefact cache (i.e. only re-runs code generation as required).
Yes interested. Happy to talk about what we do today to be as on-demand as possible. > On Sat, 26 Jan 2019 at 03:56, 'Tim Hockin' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > > 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. -- 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.
