Subject: bug#25752: closed (go incremental builds broken)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 03 Feb 2025 20:28:02 +0000

Your bug report

#25752: go incremental builds broken

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
25752: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25752
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: go incremental builds broken
From: Sharlatan Hellseher <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 03 Feb 2025 20:27:43 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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 [email-masked]+ (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@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

Subject: go incremental builds broken
From: Hank Donnay <[email-masked]>
To: [email-masked]
Date: Thu, 16 Feb 2017 10:05:27 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

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,