GNU bug report logs - #53878
[PATCH 00/11] Update Racket to 8.4. Adjust Chez Scheme

Previous Next

Package: guix-patches;

Reported by: Philip McGrath <philip <at> philipmcgrath.com>

Date: Tue, 8 Feb 2022 15:14:01 UTC

Severity: normal

Tags: patch

Merged with 53997

Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #108 received at 53878 <at> debbugs.gnu.org (full text, mbox):

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 53878 <at> debbugs.gnu.org
Subject: Re: [PATCH 07/11] gnu: chez-scheme: Explicitly package bootstrap
 bootfiles.
Date: Wed, 16 Feb 2022 16:13:36 -0500
Hi,

On 2/14/22 09:54, Liliana Marie Prikler wrote:
> Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath:
>> This might seem a bit silly in isolation, but it makes the structure
>> of the upstream Chez Scheme package the same as for the Racket
>> variant, it sets things up for (one day, hopefully) actually being
>> able to bootstrap the upstream Chez Scheme bootfiles, and it may be
>> useful for cross-compilation and adding support for architectures
>> without pre-built bootfiles from upstream.
>>
>> * gnu/packages/chez-and-racket-bootstrap.scm
>> (chez-scheme-bootstrap-bootfiles): New variable.
>> (chez-scheme)[native-inputs]: Add it.
>> [arguments]: Add new phase 'unpack-bootfiles'.
>> [version, source, home-page]: Derive from 'chez-scheme-bootstrap-
>> bootfiles'.
>> ---
> While having chez-scheme-bootstrap-bootfiles (silly name) does make
> some kind of sense, making chez-scheme inherit from it does not.  Given
> that we don't have a chez-scheme bootstrap tower at hand, you should
> probably make (chez-scheme-bootstrap) a procedure which takes chez-
> scheme's origin as argument and returns the full package.
> 
Making a function is an interesting idea, but I'm not sure I'm quite 
picturing what you have in mind. I will see if I can figure out 
something that seems reasonable as I revise this series, if I don't hear 
from you before then.

One reason I like making the bootfiles a package is that a set of 
bootfiles includes artifacts in addition to the bootfiles themselves, 
such as generated C headers describing the layout of Scheme objects in 
memory, some of which are not included as part of an installed Chez 
Scheme. For example, imagine someone wants to run Chez Scheme on 
FreeBSD: upstream does not distribute BSD bootfiles, so they must be 
cross-compiled. Even though Guix doesn't have a C toolchain for FreeBSD 
(AFAIK), Guix could be used to reproducibly build the needed bootfiles 
and pack a "source" tarball to be used on a FreeBSD build machine.

Also, the process for building bootfiles is largely orthogonal to 
building the actual `scheme` executable, and it seems like eventually it 
may be useful to be able to override options separately.

There may be other ways to address these sorts of things, and it's true 
that a lot of this has more to do with my intuition of what might be 
work well in the future, rather than something that actually works right 
now.

Is there a technical reason to prefer either repeating the home page, 
license, etc. or writing e.g. `(package-license 
chez-scheme-bootstrap-bootfiles)` rather than using inheritance?

-Philip




This bug report was last modified 2 years and 344 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.