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

Previous Next

Package: guix;

Reported by: Leo Famulari <leo <at> famulari.name>

Date: Wed, 3 Oct 2018 14:54:02 UTC

Severity: normal

To reply to this bug, email your comments to 32919 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#32919; Package guix. (Wed, 03 Oct 2018 14:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Leo Famulari <leo <at> famulari.name>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 03 Oct 2018 14:54:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: bug-guix <at> gnu.org
Cc: Katherine Cox-Buday <cox.katherine.e <at> gmail.com>
Subject: Golang build cache and content-based staleness in Guix
Date: Wed, 3 Oct 2018 10:53:35 -0400
[Message part 1 (text/plain, inline)]
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?

[0]
https://bugs.gnu.org/30579
https://golang.org/doc/go1.10#build
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#32919; Package guix. (Wed, 03 Oct 2018 16:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 32919 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

This bug report was last modified 5 years and 205 days ago.

Previous Next


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