Re: Help with channel build system and package

[Marek Paśnikowski]

08.03.2024 03:35:11 CET Jesse Millwood:
> I'm still trying to get this to work. I tracked some things I forgot and
> now have my channel hosted at:
> https://codeberg.org/moonling/guix-embedded-dev
> 
> When I try to build my toolchain package I get this:
> 
> ➜ guix build -v 4 -L guix-embedded-dev ct-ng-riscv64-unknown-elf
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 100.0%
> The following derivation will be built:
> /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0
> .drv building
> /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0
> .drv... Backtrace:
>             3 (primitive-load "/gnu/store/kghq1xz3wyb509944y9jd8vhy0l?")
> In ice-9/eval.scm:
>     191:27  2 (_ #f)
>     223:20  1 (proc #<directory (guile-user) 7ffff77f7c80>)
> In unknown file:
>             0 (%resolve-variable (7 . gexp) #<directory (guile-user) ?>)
> 
> ERROR: In procedure %resolve-variable:
> Unbound variable: gexp
> builder for
> `/gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.
> 0.drv' failed with exit code 1
> build of
> /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0
> .drv failed
> View build log at
> '/var/log/guix/drvs/wm/1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-
> elf-1.26.0.drv.gz'. guix build: error: build of
> `/gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.
> 0.drv' failed
> 
> 
> It seems the issue here is an unbound variable "gexp". I'm a little
> confused about this because I have #:use-module (guix gexp) included in
> my package and build-system/crosstool-ng.scm files. The backtrace is a
> little hard to follow.

I am self-learning Scheme and yet confident in my skills, so take what I am 
about to write with a dose of healthy scepticism.

1. From the error message alone, I do not know whether the unresolved variable 
is actually in the crosstool-ng package file, or anywhere else.

2. "gexp" or its alias "#~" do not occur in the body of the package module.  
However, the module does depend, among others that I trust to be correct, on 
the crosstool-ng build system.  There is a potential for the unresolved 
variable to live there.

3. Upon opening the build-system file, I was quickly drawn to the nested gexp 
in the definition of build procedure.  It took me some reading of the 
documentation to somewhat understand what the #$@(sexp-gexp modules) form is.  
My current understanding is that it brings an externally defined list of 
modules.

4. The (crosstool-ng-build name inputs _) definition does contain what appears 
to be a "modules" binding to a list of modules.  That list does NOT contain 
(guix gexp), and this in turn makes #~(crosstool-ng-build _) form unreadable 
to the interpreter.  Do mind that at this point the interpreter is not running 
inside the build-system file — it is working on a staged code of #~(begin _).

5. My proposed solution is to include (guix gexp) in the (define* (crosstool-
ng-build name inputs _ (modules)) form.  I have tested the change at the last 
minute — guix no longer complains about unresolved variables, but there is a 
new error about "no code for module (guix gexp)".  More work needs to be put 
into the code overall.

PS: I would appreciate it if someone who feels confident in their Scheme 
knowledge could grade my line of reasoning.  This is my first ever attempt to 
debug completely foreign code.

signature.asc
Description: This is a digitally signed message part.