From: Philip McGrath <philip@philipmcgrath.com>
To: raingloom <raingloom@riseup.net>, 48682@debbugs.gnu.org
Subject: bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)
Date: Thu, 27 May 2021 00:26:56 -0400 [thread overview]
Message-ID: <7bb14837-cd53-45f6-f572-7493c2b1bb50@philipmcgrath.com> (raw)
In-Reply-To: <20210526205455.3431430c@riseup.net>
Hi, I've been working on Racket packaging. I haven't looked into this
much yet---hopefully I can tomorrow---but here are a few quick thoughts.
On 5/26/21 2:54 PM, raingloom wrote:
> I also haven't found any other mention of chez-scheme in racket.scm
> other than the line that imports it, which is weird, given that Racket
This was my doing. When I added `(gnu packages racket)` in [1], I
adapted the patch from a racket.scm I'd been using to experiment ([2],
also some branches of [3]): the changes that actually use (gnu packages
chez) aren't ready to go yet, but apparently I left the import line in.
On 5/26/21 2:54 PM, raingloom wrote:
> other than the line that imports it, which is weird, given that Racket
> is now built on Chez, so I'd expect it to use it as an input. I guess
> it's a bundled version? In any case I don't think I should just remove
> the import, because it will be needed eventually, so this issue needs
> to be fixed by then.
Racket uses a fork of Chez Scheme: I described the situation in [4].
Racket won't have upstream Chez as an input in the foreseeable, but,
from a packaging perspective, building Racket's Chez fork uses many of
the same pieces as building upstream Chez. I think it may make sense to
refactor out some of the common infrastructure, so both `(gnu packages
racket)` and `(gnu packages chez)` could depend on some low-level
module, but I'm not sure what the Guix-preferred way to organize things
would be. (I'm mostly a Racketeer using Racket packaging to learn more
about Guix.)
Here are some ways `(gnu packages chez)` and `(gnu packages racket)` are
intertwined, in no particular order:
- `racket-minimal` should use the `nanopass` and `stex` origins
as `chez-scheme` does. (But it would be easiest to do this
once I've changed `racket-minimal` to build from the Git source,
rather than the bootstrapped tarball: I hope that will be soon.)
Some more of my not-quite-current thoughts on that at [5].
- The `chez-scheme` phases `unpack-nanopass+stex`, `configure`,
`prepare-stex`, and `install-doc` should be shared with Racket.
I think it would be better to put them in a build-side module and
actually share them, rather than to do tricky things to extract
their s-expression representation from
`(package-arguments chez-scheme)`. On the other hand, I think a
build system would be overkill: it would only build vanilla Chez
and Racket-flavored Chez.
- Racket-flavored Chez has added some backends that vanilla Chez
doesn't support (and can't be readily ported, unless upstream Chez
eventually adopts Racket's changes to generating backends).
In particular, Racket-flavored Chez adds support for threading on
ARMv6 and support for aarch64 (which vanilla Chez doesn't support at
all). I haven't thought at all deeply about this, but it might make
sense for the default `chez-scheme` package on those architectures
to be Racket-flavored Chez.
- We may in fact want to use Racket to bootstrap vanilla Chez.
Chez has the usual problem with self-hosting compilers that you
need the old version to compile the new version. Specifically, you
need "bootfiles", which encapsulate the Scheme-implemented portion
of Chez, compiled to machine code. Thus, (a) they are platform-
specific and (b) they need to agree precisely with the C-implemented
part of Chez on the layout of datatypes and such.
The vanilla Chez Git repository [6] has bootfiles for i686, x86_64,
and (non-threaded) ARMv6. Once you've done a native build for one of
those platforms, you can use it to cross-compile for any platform
Chez supports (ppc32, various BSDs, etc.). But these are binary
blobs. From a "trusting trust" perspective, it's especially striking
if you consider that Chez Scheme was non-free software from 1984 to
2016, and the first libre release likewise needed the bootfiles of
its ancestors. (However, building bootfiles is reproducible:
Chez in fact builds them twice and errors if they aren't
byte-for-byte identical.)
But Racket is able to simulate enough of Chez to (slowly)
compile the Chez compiler and generate bootfiles, providing a path
to Chez from just a C compiler. Racket does its whole bootstrapping
process regularly in CI, and I'm working on getting the Guix package
to do likewise.
Unfortunately, the Racket fork has diverged enough from vanilla Chez
that the current Racket "cs-bootstrap" package [7] can't build
vanilla Chez, but I hope that the solution is just a matter of
walking through the Git history to find the right older version of
the bootstrapping package, before the Racket fork's `#!base-rtd`
gained a vector of ancestors rather than a parent and a few such
things. But I'd like to be able to build Racket packages with Guix
before I try that :)
Ok, that got a bit long.
I don't know where the cycle came from with `emacs-geiser-racket`, but I
think it would be reasonable either to do some refactoring to `(gnu
packages chez)` and `(gnu packages racket)`, or to just remove the
import for now to un-break things and figure out the rest later.
-Philip
[1]: https://issues.guix.gnu.org/47829
[2]: https://gitlab.com/philip1/guix-racket-experiment
[3]: https://gitlab.com/philip1/guix-patches/
[4]: https://issues.guix.gnu.org/46865#3
[5]: https://issues.guix.gnu.org/47153#2
[6]: https://github.com/cisco/ChezScheme
[7]:
https://github.com/racket/racket/tree/master/racket/src/ChezScheme/rktboot
next prev parent reply other threads:[~2021-05-27 4:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 18:54 bug#48682: recursive import between (gnu packages chez) and (gnu packages racket) raingloom
2021-05-27 4:26 ` Philip McGrath [this message]
2021-05-28 2:02 ` raingloom
2021-05-28 18:19 ` Philip McGrath
2021-05-29 20:15 ` Ludovic Courtès
2021-05-29 21:42 ` Philip McGrath
2021-05-29 22:02 ` Philip McGrath
2021-05-31 16:23 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bb14837-cd53-45f6-f572-7493c2b1bb50@philipmcgrath.com \
--to=philip@philipmcgrath.com \
--cc=48682@debbugs.gnu.org \
--cc=raingloom@riseup.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.