Golang build cache and content-based staleness in Guix

  • Open
  • quality assurance status badge
Details
2 participants
  • Gábor Boskovits
  • Leo Famulari
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 3 Oct 2018 16:53
(address . bug-guix@gnu.org)(name . Katherine Cox-Buday)(address . cox.katherine.e@gmail.com)
20181003145335.GB24877@jasmine.lan
On Tue, Oct 02, 2018 at 04:49:20PM -0500, Katherine Cox-Buday wrote:
Toggle quote (3 lines)
> 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]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlu01+8ACgkQJkb6MLrK
fwhB+xAAuns5YbQRk1tZILYXRLYnFcAv1kpEvu+BG59Kd6MQHw34GpYfykYHffKC
ZWkTKk3YgjuB4W+9WzRDpgWUMAYBJgZMQ7D8qTo+tb2F+FeXa55HYIbygJ3LMWbS
QE87wkWq/8NSnZlthmlxM8yrKhHNIdBDeeIRpp2y7hV3Ztv07IHWn2fEkZSg7T9n
ff3CcAZQK/sK83BR2uG70ImCaUqltZXJUErL2JrMrvkDsobr0iujw3pdBVXbRZIr
S+UK06XQ/BORpBAJ99IvitNRRs5fIMtU1U2xZkOk+iGCiUne0MAs4sEIZEyTW393
RuMM9o+n7u7iOQcop45sK6PxxDukuM/Xwg9iFoL8CELRbXg0kLtVhVUfUlGzoJWM
rDN0ezJdSqhwUOP6ufCV4U/ZWV8i531XwW3ZDCvQW63jIIfme07FADEaSCmkTAwJ
7ERN8Ae3hbNjfHSJRnzQPSCbeJlMyMT3JnheO2Tks6PcM0gd0jgUp8TvH632Nrcd
1auvGozMIYTGewqrPnYh1G8ljErPb05gqzvybFal3mc64fgVKGpuXc3e9jvUqfXp
WsXQfOeydMIXp4UED42gUQhRTEik9UfZFp76KqhC0iDA1jf0IwHT51xxPUdr/bXo
Kb9fJxZQrNVA87J6q6f9acsLs4Jzxs8+Tlc+01oXFvlmoKRTpok=
=xfUb
-----END PGP SIGNATURE-----


G
G
Gábor Boskovits wrote on 3 Oct 2018 18:56
(name . Leo Famulari)(address . leo@famulari.name)
CAE4v=ph+aDO50zc+37TkksiT=sq-R5=DdiHABtyN1qat=+H_ow@mail.gmail.com
Leo Famulari <leo@famulari.name> ezt írta (id?pont: 2018. okt. 3., Sze,
16:54):

Toggle quote (27 lines)
> 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.


Toggle quote (4 lines)
> [0]
> https://bugs.gnu.org/30579
> https://golang.org/doc/go1.10#build
>
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 32919@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 32919
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch