guix-patches
[Top][All Lists]
Advanced

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

[bug#53878] [PATCH 08/11] gnu: Add chez-scheme-for-racket.


From: Liliana Marie Prikler
Subject: [bug#53878] [PATCH 08/11] gnu: Add chez-scheme-for-racket.
Date: Mon, 14 Feb 2022 16:18:49 +0100
User-agent: Evolution 3.42.1

Hi,

Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath:
> [...]
> * gnu/packages/chez-and-racket-bootstrap.scm (racket-vm-cgc):
> (racket-vm-bc):
> (racket-vm-cs):
> (chez-scheme-for-racket-bootstrap-bootfiles):
> (chez-scheme-for-racket): New variables.
One patch per package is probably better.

> [...] One way of thinking about the
> +;; bounary between the Racket VM and Racket programs is that the VM
> implements
boundary.

> +;; the primitives accessed by the 'ffi/unsafe/vm' library. Another
> perspective
> +;; is that DrRacket's ``Open defining file''/``Jump to definition''
> features
> +;; can navigate into Racket programs, including into the
> implementation of
> +;; 'racket/base', but can not jump into the implementation of the
> Racket VM
> +;; itself. A third, related perspective is that Racket code is
> usually
> +;; installed with source files alongside compiled code (though this
> is not
> +;; mandatory), whereas the Racket VM is installed only in compiled
> form.
> [...]
> +;; output. The function 'racket-vm-for-system' returns the
> recomended Racket
> +;; VM package for a given system.
This is a very long comment.  Consider how much of it is actually
necessary and how much of it is not (do I really need to know about the
capabilities of DrRacket for instance?)

> +;; Bootstrapping Racket:
> +;; ---------------------
> +;;
> +;; Here's how bootstrapping Racket works:
> +;;
> +;;   - Racket BC [CGC] can be built with only a C compiler (except
> for
> +;;     one caveat discussed below).
> +;;   - Racket BC [3M] needs an existing Racket to run "xform",
> +;;     which transforms its own C source code to add additional
> annotations
> +;;     for the precise garbage collector.
> +;;   - Racket CS needs (bootfiles for) Racket's fork of Chez Scheme.
> +;;     It also needs an existing Racket to compile Racket-
> implemented
> +;;     parts of the runtime system to R6RS libraries.
> +;;   - Chez Scheme also needs bootfiles for itself, but Racket can
> simulate
> +;;     enough of Chez Scheme to load Racket's fork of the Chez
> Scheme compiler
> +;;     purely from source into Racket and apply the compiler to
> itself,
> +;;     producing the needed bootfiles (albeit very slowly).
> +;;     Any variant of Racket since version 7.1 can run the
> simulation.
> +;;
> +;; So, we build CGC to build 3M to build bootfiles and CS.
This block I'd consider necessary, but again slightly on the verbose
end.

> +;; (Note: since the CGC variant is basically only for bootstrapping,
> we
> +;; often use "BC" to mean "3M", consistent with `(banner)` and the
> +;; suffixes used on executables when more than one variant co-
> exists.)
> +;;
> +;; One remaining bootstrapping limitation is that Racket's reader,
> module
> +;; system, and macro expander are implemented in Racket. For Racket
> CS,
> +;; they are compiled to R6RS libraries as discussed above. This note
> from the
> +;; README file applies to all such subsystems:
> +;;
> +;;     The Racket version must be practically the same as the
> current Racket
> +;;     verson, although it can be the Racket BC implementation
> (instead of
> +;;     the Racket CS implementation).
> +;;
> +;;     Unlike Chez Scheme boot files, the files generated in
> "schemified"
> +;;     are human-readable and -editable Scheme code. That provides a
> way
> +;;     out of bootstrapping black holes, even without BC.
> +;;
> +;; However, other Racket subsystems implemented in Racket for Racket
> CS
> +;; use older C implementations for Racket BC, whereas the reader,
> expander,
> +;; and module system were completely replaced with the Racket
> implementation
> +;;
> +;; For Racket BC, the compiled "linklet" s-expressions (primitive
> modules)
> +;; are embeded in C as a static string constant. Eventually, they
> are further
> +;; compiled by the C-implemented Racket BC bytecode and JIT
> compilers.
> +;; (On platforms where Racket BC's JIT is not supported, yet another
> compiler
> +;; instead compiles the linklets to C code, but this is not a
> bootstrapping
> +;; issue.)
> +;;
Again, you want to be brief and understandable.  What does this mean in
practise?  Do we have racket bootstrapped yet or is there still some
magic hidden within?

>  ;; Code:
>  
>  (define (chez-machine->unthreaded mach)
> @@ -189,19 +330,19 @@ (define* (nix-system->chez-machine #:optional
> (system (%current-system))
>                  (chez-machine->threaded mach)))))))
>  
>  ;;
> -;; Chez Scheme:
> +;; Chez auxiliary G-expressions:
>  ;;
>  
>  (define unbundle-chez-submodules
>    #~(begin
>        (use-modules (guix build utils))
>        (for-each (lambda (dir)
> -                (when (directory-exists? dir)
> -                  (delete-file-recursively dir)))
> -              '("stex"
> -                "nanopass"
> -                "lz4"
> -                "zlib"))))
> +                  (when (directory-exists? dir)
> +                    (delete-file-recursively dir)))
> +                '("stex"
> +                  "nanopass"
> +                  "lz4"
> +                  "zlib"))))
As in one of your previous patches, you're mixing cosmetic changes with
non-cosmetic ones.  This one could be prevented by correctly indenting
it in the patch that introduces it.

>  (define unpack-nanopass+stex
>    #~(begin
> @@ -216,6 +357,234 @@ (define unpack-nanopass+stex
>            ;; otherwise, it will try to download submodules
>            (display "# to placate ../configure")))))
>  
> +;;
> +;; Racket VM:
> +;;
> +
> +(define (racket-vm-common-configure-flags)
> +  ;; under a lambda extraction to avoid evaluating bash-minimal too
> early
> +  #~`(,@(cond
> +         ((false-if-exception
> +           (search-input-file %build-inputs "/bin/libtool"))
> +          => (lambda (libtool)
> +               (list (string-append "--enable-lt=" libtool))))
> +         (else
> +          '()))
> +      ,@(cond
> +         ((false-if-exception
> +           (search-input-file %build-inputs "/opt/racket-
> vm/bin/racket"))
Did we have /opt/racket... before?  We should probably avoid such
paths.
> +          => (lambda (racket)
> +               (list (string-append "--enable-racket=" racket))))
> +         (else
> +          '()))
> +      ,(string-append "CPPFLAGS=-DGUIX_RKTIO_PATCH_BIN_SH="
> +                      #$(file-append bash-minimal "/bin/sh"))
> +      "--disable-strip"
> +      "--enable-origtree")
For the record, why do you need double quoting here?  Would ungexp-
splicing extract this too soon?

> +(define-public racket-vm-cgc
> +  ;; Eventually, it may make sense for some vm packages to not be
> hidden,
> +  ;; but this one is especially likely to remain hidden.
> +  (hidden-package
> +   (package
> +     (name "racket-vm-cgc")
> +     (version "8.4")
> +     ;; ^ Remember to also update the version of
> +     ;;   chez-scheme-for-racket-bootstrap-bootfiles
> +     (source
> +      (origin
> +        (method git-fetch)
> +        (uri (git-reference
> +              (url "https://github.com/racket/racket";)
> +              (commit (string-append "v" version))))
> +        (sha256
> +         (base32
> "1vpl66gdgc8rnldmn8rmb7ar9l057jqjvgpfn29k57i3c5skr8s6"))
> +        (file-name (git-file-name "racket" version))
> +        (patches (search-patches "racket-minimal-sh-via-rktio.patch"
> +                                 ;; Remove by Racket 8.5:
> +                                 "racket-enable-scheme-
> backport.patch"))
> +        (modules '((guix build utils)))
> +        (snippet
> +         #~(begin
> +             ;; Unbundle Chez submodules.
> +             (with-directory-excursion "racket/src/ChezScheme"
> +               #$unbundle-chez-submodules)
> +             ;; Unbundle libffi.
> +             (delete-file-recursively
> "racket/src/bc/foreign/libffi")))))
> +     (inputs (list ncurses ;; <- common to all variants (for
> #%terminal)
> +                   bash-minimal ;; <- common to all variants (for
> `system`)
> +                   libffi)) ;; <- only for BC variants
> +     (native-inputs (list libtool)) ;; <- only for BC variants
> +     (outputs '("out" "debug"))
> +     (build-system gnu-build-system)
> +     (arguments
> +      (list
> +       #:configure-flags
> +       #~(cons "--enable-cgcdefault"
> +               #$(racket-vm-common-configure-flags))
> +       ;; Tests are in packages like racket-test-core and
> +       ;; main-distribution-test that aren't part of the main
> +       ;; distribution.
> +       #:tests? #f
> +       ;; Upstream recommends #:out-of-source?, and it does
> +       ;; help with debugging, but it confuses `install-license-
> files`.
> +       #:modules '((ice-9 match)
> +                   (ice-9 regex)
> +                   (guix build gnu-build-system)
> +                   (guix build utils))
> +       #:strip-directories #~'("opt/racket-vm/bin"
> +                               "opt/racket-vm/lib")
> +       #:phases
> +       #~(let ()
> +           (define* ((wrap-racket-vm-outputs phase) . args)
> +             (apply
> +              phase
> +              (let loop ((args args))
> +                (match args
> +                  ((#:outputs outputs . args)
> +                   `(#:outputs
> +                     ,(let loop ((outputs outputs))
> +                        (match outputs
> +                          ((("out" . out) . outputs)
> +                           `(("out" . ,(string-append out
> "/opt/racket-vm/"))
> +                             ,@outputs))
> +                          ((other . outputs)
> +                           (cons other (loop outputs)))))
> +                     ,@args))
> +                  ((arg . args)
> +                   (cons arg (loop args)))))))
Why?


Cheers





reply via email to

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