Re: Help with channel build system and package

[Jesse Millwood <jesse_m@fastmail.com>]

Marek,

Thanks for the detailed response! I really appreciate it.

I responded inline. Is your main source of knowledge the official Guix 
documentation?

On 3/8/24 05:43, Marek Paśnikowski wrote:
> 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.
I am very much self learning as well. I've been comparing build system 
files and package files in my channel with upstream ones and pouring 
over the documentation. Any tips are very welcome!
> 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.
Oh interesting, I didn't know "#~" was an alias for "gexp"! I see that 
now in the G-Expressions section of the manual.
> 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.
Interesting, this is a line that I didn't quite understand and mainly 
took from similar build systems in the guix source.
> 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 _).
Oh this is very good information, thanks!
> 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.

Very interesting, thanks for trying that out! I'll incorporate it and 
keep digging!I do wonder why this is not included in other build systems 
in Guix? For example in guix/build-system/ruby.scm:

(define %ruby-build-system-modules ;; Build-side modules imported by 
default. `((guix build ruby-build-system) ,@%gnu-build-system-modules))

...

(define* (ruby-build name inputs #:key source (gem-flags ''()) 
(test-target "test") (tests? #t) (phases '%standard-phases) (outputs 
'("out")) (search-paths '()) (system (%current-system)) (guile #f) 
(imported-modules %ruby-build-system-modules) (modules '((guix build 
ruby-build-system) (guix build utils))))

This is one that I have been basing my crosstool-ng build system on. I 
appreciate your analysis!

> 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.