[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54292: Commit e8518c43 breaks guix pull on i686
From: |
Liliana Marie Prikler |
Subject: |
bug#54292: Commit e8518c43 breaks guix pull on i686 |
Date: |
Tue, 08 Mar 2022 21:49:32 +0100 |
User-agent: |
Evolution 3.42.1 |
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