On Tuesday, March 8, 2022 10:32:48 AM EST Liliana Marie Prikler wrote: > > The error appears to be that nix-system->chez-machine was rather poorly > coded and overlooked in review. In particular, i686 should probably > also default to the i386 case. >
I must for some reason not have been thinking about the fact that Guix
distinguishes among "i[3456]86" when I ported `%nix-arch-to-chez-alist` from
the `raco cross` codebase.
I can see (at least) two paths forward:
1. `%nix-{arch,os}-to-chez-alist` could become many-to-one rather than
one-to-one. Presumably we'd use the first applicable entry when going
from Chez to Nix.
2. We could give up on alists and use existing predicates from (guix utils)
like `target-x86-32?`, as Liliana had already suggested during review for
`chez-upstream-features-for-system`.
I liked the alists because they made the bidirectional relationship obvious,
but I wonder if there are other potential pitfalls analogous to this one.
Maybe someone more familiar with non-x86_64 systems in Guix/Nix than I am
should decide.
OTOH, while it's definitely a bug that
`(nix-system->chez-machine "i686-linux")` currently returns `#f`, it seems
like the more immediate problem is from the `maybe-compile` phase of the stex-
bootstrap package, where this code:
(define machine
#$(chez-machine->threaded
(nix-system->chez-machine)))
assumes, apparently incorrectly, that it's only going to be run when the
result of `nix-system->chez-machine` is non-false. In other words, even if we
fix the bug in `nix-system->chez-machine` for i686, I think we'd still hit
this problem for systems that Chez really doesn't support, e.g. ppc64le or
MIPS. I don't know what the most correct way would be to write this code, but
I think we could defer the error until someone attempts to build the package
for the unsupported system by just writing something like:
(define machine
#$(and=> (nix-system->chez-machine)
chez-machine->threaded))
-Philip
signature.asc
Description: This is a digitally signed message part.
