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

[Philip McGrath]

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