GNU bug report logs - #32919
Golang build cache and content-based staleness in Guix

Previous Next

Full log

View this message in rfc822 format

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: Katherine Cox-Buday <cox.katherine.e <at> gmail.com>, 32919 <at> debbugs.gnu.org
Subject: bug#32919: Golang build cache and content-based staleness in Guix
Date: Wed, 3 Oct 2018 18:56:19 +0200

[Message part 1 (text/plain, inline)]

Leo Famulari <leo <at> famulari.name> ezt írta (időpont: 2018. okt. 3., Sze,
16:54):

> On Tue, Oct 02, 2018 at 04:49:20PM -0500, Katherine Cox-Buday wrote:
> > We should perhaps begin thinking about switching the Go build system to
> > the 1.11 series of releases.
>
> I agree. When Go 1.11 was released, Go 1.9 became unsupported upstream,
> so we should stop using it.
>
> The go-build-system as implemented in Guix worked great through Go 1.9.
>
> Go 1.10 changed how the Go compiler chooses whether or not to re-use
> compiled Go objects, using a technique they call "content-based
> staleness", which is basically a memoized cache, similar to Guix. [0]
>
> For us, the downside of that change is that, when building within Guix
> using the tools we have now, the Go compiler never re-uses compiled
> objects and instead rebuilds everything, every time. That is, the Go
> build cache is never hit. It's inefficient but nothing breaks from what
> I've seen.
>
> It would be great if our go-build-system could be updated to work with
> the new Go build cache, but in my opinion it's not a blocker. I think we
> will have to change it eventually, because they seem to be phasing out
> $GOPATH, but we are good for now.
>
> What do you think?
>
>
I think we should go for it. I don't think the cache issue is a blocker.


> [0]
> https://bugs.gnu.org/30579
> https://golang.org/doc/go1.10#build
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.