[bug#53878,v2,08/15] gnu: chez-scheme: Explicitly package bootstrap bootfiles.

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]<#:phases>: Add 'unpack-bootfiles'.
---
 gnu/packages/chez-and-racket-bootstrap.scm | 51 +++++++++++++++++++++-
 1 file changed, 49 insertions(+), 2 deletions(-)

Am Donnerstag, dem 17.02.2022 um 15:50 -0500 schrieb Philip McGrath:
> +(define-public chez-scheme-bootstrap-bootfiles
> +  (package
> +    (inherit chez-scheme)
> +    (name "chez-scheme-bootstrap-bootfiles")
> +    (inputs '())
> +    (native-inputs '())
> +    (outputs '("out"))
> +    (build-system copy-build-system)
> +    ;; TODO: cross compilation
This TODO might be moved one line up, since you wouldn't be able to do
cross-compilation with just copy-build-system, would you?
> +    (arguments
> +     (list #:install-plan
> +           #~`(("boot/" "lib/chez-scheme-bootfiles"))))
> +    (supported-systems
> +     ;; Upstream only distributes pre-built bootfiles for
> +     ;; arm32le and t?(i3|a6)(le|nt|osx)
> +     (filter (lambda (system)
> +               (let ((machine (and=> (nix-system->chez-machine
> system)
> +                                     chez-machine->nonthreaded)))
> +                 (or (equal? "arm32le" machine)
> +                     (and machine
> +                          (member (substring machine 0 2) '("i3"
> "a6"))
> +                          (or-map (cut string-suffix? <> machine)
> +                                  '("le" "nt" "osx"))))))
> +             %supported-systems))
> +    (synopsis "Chez Scheme bootfiles (binary seed)")
> +    (description
> +     "Chez Scheme is a self-hosting compiler: building it requires
> +``bootfiles'' containing the Scheme-implemented portions compiled
> for the
> +current platform.  (Chez can then cross-compile bootfiles for all
> other
> +supported platforms.)
> +
> +This package provides bootstrap bootfiles for upstream Chez Scheme.
> +Currently, it simply packages the binaries checked in to the upsream
> +repository.  Hopefully we can eventually adapt Racket's @code{cs-
> bootstrap} to
> +work with upstream Chez Scheme so that we can bootstrap these files
> from
> +source.")))
> +
Now to explain the difference between my suggestion and what you
implemented.  Mine would be to 
(define-public (chez-scheme-bootstrap-bootfiles chez-scheme)
  ...)
where ... is the code you already have.  This would not only work for
other chez-schemes than the one we have packaged, but might also make
it possible to cross module boundaries, i.e. keep chez-scheme in
chez.scm.  WDYT?

Hi,

On Friday, February 18, 2022 2:08:46 AM EST Liliana Marie Prikler wrote:
> Am Donnerstag, dem 17.02.2022 um 15:50 -0500 schrieb Philip McGrath:
> > +(define-public chez-scheme-bootstrap-bootfiles
> > +  (package
> > +    (inherit chez-scheme)
> > +    (name "chez-scheme-bootstrap-bootfiles")
> > +    (inputs '())
> > +    (native-inputs '())
> > +    (outputs '("out"))
> > +    (build-system copy-build-system)
> > +    ;; TODO: cross compilation
> 
> This TODO might be moved one line up, since you wouldn't be able to do
> cross-compilation with just copy-build-system, would you?
> 

Actually, for the bootfiles, I would do cross-compilation with `copy-build-
system`: the extra parts of `gnu-build-system` would just have to be deleted 
anyway. With the definition of `chez-scheme-for-racket-bootstrap-bootfiles` in 
patch v2 11/15, you could get a kind of cross compilation just by changing:

    (add-before 'install 'build
      (lambda* (#:key native-inputs inputs #:allow-other-keys)
        (invoke (search-input-file (or native-inputs inputs)
                                   "/opt/racket-vm/bin/racket")
                "rktboot/main.rkt")))

to:

    (add-before 'install 'build
      (lambda* (#:key native-inputs inputs #:allow-other-keys)
        (invoke (search-input-file (or native-inputs inputs)
                                   "/opt/racket-vm/bin/racket")
                "rktboot/main.rkt"
                "--machine"
                (chez-maching->threaded
                 (chez-machine-for-system))))))

(I don't recommend that: for one thing, it would be about ten times slower 
than taking Chez Scheme as a native input when cross-compiling. More 
significantly, the harder questions about cross-compilation are in the Chez 
Scheme package itself, not the bootfiles. Perhaps we will end up wanting 
packages like `chez-scheme-bootstrap-bootfiles-ta6le` and  `chez-scheme-
bootstrap-bootfiles-ti3le`, analogous to e.g. `gcc-cross-sans-libc-arm-none-
eabi` and  `binutils-cross-x86_64-w64-mingw32`. Or maybe it will make sense to 
have one package build bootfiles for all supported machine types in separate 
outputs, and a variant of that for bootstrapping that goes through Racket for 
just the current machine type. Those are questions for another day.)

> > +    (arguments
> > +     (list #:install-plan
> > +           #~`(("boot/" "lib/chez-scheme-bootfiles"))))
> > +    (supported-systems
> > +     ;; Upstream only distributes pre-built bootfiles for
> > +     ;; arm32le and t?(i3|a6)(le|nt|osx)
> > +     (filter (lambda (system)
> > +               (let ((machine (and=> (nix-system->chez-machine
> > system)
> > +                                     chez-machine->nonthreaded)))
> > +                 (or (equal? "arm32le" machine)
> > +                     (and machine
> > +                          (member (substring machine 0 2) '("i3"
> > "a6"))
> > +                          (or-map (cut string-suffix? <> machine)
> > +                                  '("le" "nt" "osx"))))))
> > +             %supported-systems))
> > +    (synopsis "Chez Scheme bootfiles (binary seed)")
> > +    (description
> > +     "Chez Scheme is a self-hosting compiler: building it requires
> > +``bootfiles'' containing the Scheme-implemented portions compiled
> > for the
> > +current platform.  (Chez can then cross-compile bootfiles for all
> > other
> > +supported platforms.)
> > +
> > +This package provides bootstrap bootfiles for upstream Chez Scheme.
> > +Currently, it simply packages the binaries checked in to the upsream
> > +repository.  Hopefully we can eventually adapt Racket's @code{cs-
> > bootstrap} to
> > +work with upstream Chez Scheme so that we can bootstrap these files
> > from
> > +source.")))
> > +
> 
> Now to explain the difference between my suggestion and what you
> implemented.  Mine would be to
> (define-public (chez-scheme-bootstrap-bootfiles chez-scheme)
>   ...)
> where ... is the code you already have.  This would not only work for
> other chez-schemes than the one we have packaged, but might also make
> it possible to cross module boundaries, i.e. keep chez-scheme in
> chez.scm.  WDYT?

I still don't think I understand. How would this avoid having to override 
almost everything for both the upstream and Racket variants of the package, as 
was the case in my attempt in <https://issues.guix.gnu.org/53878#44> (also at 
<https://gitlab.com/philip1/guix-patches/-/blob/guix-issue-53878-v2-bootfiles-proc/gnu/packages/chez-and-racket-bootstrap.scm#L723>)? I mean, you could put 
the upstream stuff under the `lambda` for now, but eventually it will also need 
a build phase and some inputs. I just don't see what the benefit all that would 
achieve, or what the problem is (if there is one) with this patch.

-Philip

Am Freitag, dem 18.02.2022 um 18:20 -0500 schrieb Philip McGrath:
> > Now to explain the difference between my suggestion and what you
> > implemented.  Mine would be to
> > (define-public (chez-scheme-bootstrap-bootfiles chez-scheme)
> >   ...)
> > where ... is the code you already have.  This would not only work
> > for other chez-schemes than the one we have packaged, but might
> > also make it possible to cross module boundaries, i.e. keep chez-
> > scheme in chez.scm.  WDYT?
> 
> I still don't think I understand. How would this avoid having to
> override almost everything for both the upstream and Racket variants
> of the package, as 
> was the case in my attempt in <https://issues.guix.gnu.org/53878#44>
> (also at 
> <
> https://gitlab.com/philip1/guix-patches/-/blob/guix-issue-53878-v2-bootfiles-proc/gnu/packages/chez-and-racket-bootstrap.scm#L723
> >)? I mean, you could put 
> the upstream stuff under the `lambda` for now, but eventually it will
> also need a build phase and some inputs. I just don't see what the
> benefit all that would achieve, or what the problem is (if there is
> one) with this patch.
The concern is not w.r.t variants, but version bumps, assuming that
bootstrap mostly stays the same from e.g. Racket 8.4 → 8.5 (I don't
have the Chez version in the back of my head atm, but you get the gist)

Will be looking at v3.