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: Hank Donnay <hdonnay <at> gmail.com>
Subject: bug#25752: closed (go incremental builds broken)
Date: Mon, 03 Feb 2025 20:28:02 +0000

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

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 25752 <at> debbugs.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: 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 3 (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)]

[Message part 5 (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,

Previous Next

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