GNU bug report logs - #25752
go incremental builds broken

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Sharlatan Hellseher <sharlatanus <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#25752: closed (go incremental builds broken)
Date: Mon, 03 Feb 2025 20:28:01 +0000

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

Your message dated Mon, 03 Feb 2025 20:27:43 +0000
with message-id <871pwelqo0.fsf <at> gmail.com>
and subject line go incremental builds broken
has caused the debbugs.gnu.org bug report #25752,
regarding go incremental builds broken
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
25752: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25752
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Hank Donnay <hdonnay <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: go incremental builds broken
Date: Thu, 16 Feb 2017 10:05:27 -0500

Hello,

It seems the guix's go package is broken when the go tool is used for
incremental builds. Any attempt to use 'install' or 'build -i' results
in an attempt to write to the store. A one-liner:

    guix environment --ad-hoc go -- bash -c 'export t=$(mktemp -d); cd
$t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install cmd/go; cd
&& rm -rf $t'

Another command reports that (seemingly) the entire stdlib is marked as stale:

    guix environment --ad-hoc go -- bash -c 'export t=$(mktemp -d); cd
$t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go list -f '\''{{join
.Deps "\n"}}'\'' cmd/go | xargs -n1 go list -f '\''{{if
.Stale}}{{.ImportPath}}: {{.StaleReason}}{{end}}'\''; cd && rm -rf $t'

The function for determining staleness is here (after the giant
comment explaining the reasoning):
https://golang.org/src/cmd/go/pkg.go#L1111

I don't see anything wrong with the package definition, but could be
missing something. My only hunch at this point is that something might
be modifying src/runtime/internal/sys/zversion.go, as that entire file
is included in the build ID computation.

Thanks,

[Message part 3 (message/rfc822, inline)]

From: Sharlatan Hellseher <sharlatanus <at> gmail.com>
To: 25752-done <at> debbugs.gnu.org
Cc: maxim.cournoyer <at> gmail.com, zimon.toutoune <at> gmail.com, ludo <at> gnu.org,
 efraim <at> flashner.co.il, leo <at> famulari.name, hdonnay <at> gmail.com
Subject: go incremental builds broken
Date: Mon, 03 Feb 2025 20:27:43 +0000

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

Hi

I think it's a time to close it for now.

<https://golang.org/src/cmd/go/pkg.go#L1111> leads to 404
--8<---------------cut here---------------start------------->8---
to, err := human()
open src/cmd/go/pkg.go: file does not exist
--8<---------------cut here---------------end--------------->8---

This just lists internal modules coming with go source, and no go-*
packages are used during the build:
--8<---------------cut here---------------start------------->8---
go list -f '{{join .Deps "\n"}}' cmd/go
--8<---------------cut here---------------end--------------->8---

The attempt to find out the purpose of 'pkg/' leads me to a deep search
kung-fu with a few information in official Documentation.
- https://stackoverflow.com/questions/47369621/what-is-the-use-of-pkg-directory-in-go
- https://go.dev/doc/code#Workspaces

I would not treat this statement as something relevant to go <at> 1.19+ (we
have 1.21 as a default for build):
- https://github.com/golang-standards/project-layout?tab=readme-ov-file#pkg
--8<---------------cut here---------------start------------->8---
Library code that's ok to use by external applications (e.g.,
/pkg/mypubliclib). Other projects will import these libraries expecting
them to work, so think twice before you put something here :-) Note that
the internal directory is a better way to ensure your private packages
are not importable because it's enforced by Go. The /pkg directory is
still a good way to explicitly communicate that the code in that
directory is safe for use by others.
--8<---------------cut here---------------end--------------->8---

I'm not sure that anyone uses Guix in Golang development and dependency
management, while go-build-system is heavily tweaked to produce just final
output for the user's command binary.

I'm also not sure if it's by design or it's a bug, if it's by disign "go
env" does not provide any relevant environment variable which may be
tweaked like we did for others in go-build-system:
--8<---------------cut here---------------start------------->8---
guix shell -D go -- bash -c 'export t=$(mktemp -d); cd $t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install cmd/go'
<...>
cmd/go: go install cmd/go: copying /tmp/go-build7392385/b001/exe/a.out: open /gnu/store/ah4ni8qjiffgw2100hl4bqffgydi7jkv-go-1.21.13/lib/go/bin/go: read-only file system
--8<---------------cut here---------------end--------------->8---

But... I can do this, which ignores all the packages availalbe in
/gnu/store and just downloads everything from Inherent then builds with
success:
--8<---------------cut here---------------start------------->8---
guix shell -D go kubo -- bash -c 'export t=$(mktemp -d); cd $t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install github.com/ipfs/kubo/cmd/ipfs <at> latest; pwd; ls $t'
<...>
/tmp/tmp.HB3jKQBvco
bin  pkg
/tmp/tmp.HB3jKQBvco/bin/ipfs --version
ipfs version 0.33.0
--8<---------------cut here---------------end--------------->8---

It's a good opportunity for GCD ;-) where we may discus how to tweak
go-build-system even more to utilize available go-* packages from the
store during development.
<https://issues.guix.gnu.org/74736>

Based on above the issue is closed. 

--
Oleg

[signature.asc (application/pgp-signature, inline)]

Previous Next

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