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