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