guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53878] [PATCH 07/11] gnu: chez-scheme: Explicitly package bootstrap


From: Philip McGrath
Subject: [bug#53878] [PATCH 07/11] gnu: chez-scheme: Explicitly package bootstrap bootfiles.
Date: Thu, 17 Feb 2022 03:06:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

Hi,

On 2/17/22 02:10, Liliana Marie Prikler wrote:
Hi,

Am Mittwoch, dem 16.02.2022 um 16:13 -0500 schrieb Philip McGrath:
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.
I was picturing something like

(define chez-bootfiles (chez ...)
   (package/inherit chez
     (inputs ...)
     (native-inputs ...)
     (build-system ...)
     (arguments ...)))


Sorry, I still don't think I'm following. Would this rely on the `mative-inputs` being thunked to let the result of this function be an input to `chez-scheme`? What commonality is the function abstracting over, compared to having 'chez-scheme-for-racket-bootstrap-bootfiles' inherit from 'chez-scheme-bootstrap-bootfiles'?

(I'm using "-bootstrap-bootfiles" because there are also other kinds of bootfiles: applications can create their own bootfiles, e.g. "racket.boot", and using Chez as a cross-compiler also involves more bootfiles.)

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?
You should not write (package-license chez-scheme-bootstrap-files),
that's the point!  For one, that's exactly what inheritance would do
unless you specify the field (technical reason), but more importantly,
as a reader, using (package-license this-other-chez-thing) sends me on
a journey to track down this-other-chez-thing while determining the
license of chez!  That's just silly (social reason).

That makes some sense with respect to the license and home page, but what about 'package-source' and 'package-version'?

-Philip





reply via email to

[Prev in Thread] Current Thread [Next in Thread]