bug#54292: Commit e8518c43 breaks guix pull on i686

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Dienstag, dem 08.03.2022 um 13:33 -0500 schrieb Philip McGrath:
> 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.
There is no 1:1 mapping to be found here as far as I can see. 
Likewise, the reverse mapping is currently unused and should in my
opinion be dropped so that people don't expect a round-trip to be well-
defined.

> 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))
I pushed that definition upstream, but a rewrite is still needed.  I
also think this logic should be a little decoupled from the question of
whether or not a given nix-system is supported.  While surely this
function returning #f means it's not, there are still other questions
to consider.

An implementation could look like the following

(define* (nix-system->chez-machine system #:key threaded?)
  (false-if-exception
   (string-append
    (if threads? "t" "")
    (cond
     ((target-x86_64? system) "a6")
     ...)
    (cond 
     ((target-linux? system) "le")
     ...))))

Cheers