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

[Liliana Marie Prikler]

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 ...)))

> 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.
Again, I'm with you on making chez-bootfiles a package and your
rationale sounds reasonable, but I don't think it's correct to say that
chez inherits from them.  IIUC it is rather the other way around; the
bootfiles contain precompiled versions of Chez among other things.

> 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).

Cheers