[bug#53878] [PATCH v2 01/15] gnu: chez-scheme: Move to (gnu packages chez-and-racket-bootstrap).

[Philip McGrath <philip@philipmcgrath.com>]

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

Hi,

On Friday, February 18, 2022 1:57:22 AM EST Liliana Marie Prikler wrote:
> Am Donnerstag, dem 17.02.2022 um 15:50 -0500 schrieb Philip McGrath:
> > * gnu/packages/chez.scm (nanopass, stex, chez-scheme): Move to ...
> > * gnu/packages/chez-and-racket-bootstrap.scm: ... this new file.
> > * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
> > * gnu/packages/emacs-xyz.scm: Adjust imports accordingly.
> > * gnu/packages/loko.scm: Likewise.
> > * gnu/packages/racket.scm: Likewise.
> 
> For the record, why is chez-scheme moved to bootstrap?  W.r.t. the
> adjusted imports it might be a good idea to re-export it from chez.scm
> instead, but I'd need confirmation from the others on that.

Prior to this commit, there was logically a dependency cycle involving "gnu/
packages/chez.scm" and "gnu/packages/racket.scm". While it is possible, with 
great care, to avoid premature variable references that trigger Guile 
exceptions, it is easy to get wrong. At least twice Guix has ended up needing 
repairs, in:

> commit c094e574f2b78b2f090aa740c1284418c16b2fcd
> Author: raingloom <raingloom@riseup.net>
> Date:   Fri May 28 03:59:16 2021 +0200
> 
>     gnu: Break up import loop between (gnu packages racket) and (gnu
>     packages chez).
>     
>     * gnu/packages/racket.scm: Remove (gnu packages chez) import.
>     
>     Signed-off-by: Ludovic Courtès <ludo@gnu.org>

and again in:

> commit 96db2ff145ecbd962206eae815b065bda7ed3d9f
> Author: Ludovic Courtès <ludo@gnu.org>
> Date:   Tue Sep 7 15:11:46 2021 +0200
> 
>     gnu: racket-minimal: Remove top-level reference to 'chez-scheme'.
>     
>     This could cause build errors; for instance, doing:
>       make && touch gnu/packages/chez.scm && make
>     
>     would trigger a "chez-scheme: unbound variable" error.
>     
>     * gnu/packages/racket.scm (racket-minimal)[source]: Add 'modules'
>     field.  In 'snippet', remove top-level reference to CHEZ-SCHEME, which
>     could cause build errors.  Simplify snippet.

The logical cycle will only get more tangled when we can actually bootstrap 
Chez, as upstream Chez will then need Racket as a native input, like `chez-
scheme-for-racket` does now.

So, in this commit, I moved everything involved in that cycle into "chez-and-
racket-bootstrap.scm". Since building the Chez Scheme and Racket compilers is 
almost entirely unlike building packages that use the one of the compilers, 
there's some logic to it organizationally, as well, but the motivation is to 
try to make it harder to break Guix in practice.

I did try to have `(gnu packages chez)` re-export `chez-scheme`, but that 
caused build errors—rather illustrating the point. It does seem possible that, 
with the introduction of `chez-scheme-for-system`, the extra level of lambda 
extraction might be enough that it could be reexported from `(gnu packages 
chez)`. But I think it would be better for someone with a far deeper 
understanding of the potential pitfalls than mine to do that as a separate 
commit, if it seems worth doing.

-Philip

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]