Hello!
Rutherther <[email protected]> skribis:
> I am wondering, what are the disadvantages for making fields of records
> thunked? I can come up with just one, that the error messages are harder
> to read. Am I missing something?
The disadvantages are:
1. code bloat (more code is generated for each site that builds a new
record and for each site that accesses the thunked field);
2. run-time overhead (a procedure call instead of a pointer
dereference when accessing the field);
3. delayed + repeated evaluation (the field’s thunk is called every
time the field is accessed).
Depending on the situation, each one of these may or may not be a
problem. One has to be very careful with the <package> and <origin>
record types (we have 30k of each at run time!), less so for other
types.
> - operating-system bootloader field
>
> I came upon this use case when trying to make the Guix installer and
> VM image work on AArch64. Since AArch64 dooes not support grub-pc, the
> bootloader has to be changed for the grub-efi-bootloader, but for
> x86_64 we want the grub bootloader. It would be nice if I could just
> check the target in the bootloader field.
Is using ‘let-system’ an option in this context?
(I’m wary of referring to the ‘%current-system’ parameter from a
declarative context like an ‘operating-system’ declaration.)
> - operating-system packages field
>
> Similarly to the bootloader use case, specifically for the installer
> grub is put into the packages field and it would be nice if one could
> filter the supported packages.
Sounds OK.
> - package source field
>
> qemu is failing to build on some AArch64 machines, see
> <https://codeberg.org/guix/guix/issues/2447> after a patch has been
> removed from the source snippets. One workaround would be to reinstate
> the snippet, but just for AArch64.
So far, we’ve added a patch that invokes ‘patch’ in such situation.
I would avoid making ‘source’ thunked without a more compelling reason,
for the reasons given above.
I hope that makes sense!
Thanks,
Ludo’.
