| Message ID | 20220213215127.218952-8-philip@philipmcgrath.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Update Racket to 8.4. Adjust Chez Scheme packages. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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. Also, while technically a violation of the DRY principle, you are allowed to type out the homepage multiple times.
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. 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. There may be other ways to address these sorts of things, and it's true that a lot of this has more to do with my intuition of what might be work well in the future, rather than something that actually works right now. 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? -Philip
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
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
Hi, Am Donnerstag, dem 17.02.2022 um 03:06 -0500 schrieb Philip McGrath: > Hi, > > On 2/17/22 02:10, Liliana Marie Prikler wrote: > > [...] > > 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`? Yes. > What commonality is the function abstracting over, compared to having > 'chez-scheme-for-racket-bootstrap-bootfiles' inherit from 'chez- > scheme-bootstrap-bootfiles'? At the moment version, source, home-page and license. I don't really think bootstrap files ought to be a part of chez' source, so if you wanted to do this really cleanly, you'd have to drop them from chez and add restrict chez-bootstrap to them, which would imply you'd have to use (version (package-version chez-scheme)) explicitly – for now I don't want to add too much burden to that patch and you can assume source to be the same between the two. > (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.) I have no idea how useful that feature is or how widely it is used, but if those are just binary blobs needed to get chez scheme running, we ought to treat them as that. That makes some sense with respect to the license and home page, but > > > That makes some sense with respect to the license and home page, but > what about 'package-source' and 'package-version'? Your patch currently makes them the same for both, so you tell me :P See above for long-term plans. Cheers
Hi, On 2/17/22 03:19, Liliana Marie Prikler wrote: > Hi, > > Am Donnerstag, dem 17.02.2022 um 03:06 -0500 schrieb Philip McGrath: >> Hi, >> >> On 2/17/22 02:10, Liliana Marie Prikler wrote: >>> [...] >>> 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`? > Yes. > >> What commonality is the function abstracting over, compared to having >> 'chez-scheme-for-racket-bootstrap-bootfiles' inherit from 'chez- >> scheme-bootstrap-bootfiles'? > At the moment version, source, home-page and license. I don't really > think bootstrap files ought to be a part of chez' source, so if you > wanted to do this really cleanly, you'd have to drop them from chez and > add restrict chez-bootstrap to them, which would imply you'd have to > use (version (package-version chez-scheme)) explicitly – for now I > don't want to add too much burden to that patch and you can assume > source to be the same between the two. > Ok, this helps, I think. I'll give it a try. In <https://issues.guix.gnu.org/47153#9> you argued---and convinced me---that we should keep the pre-built bootfiles in the origin until we actually don't need them. With 'chez-scheme-for-racket', that's already true, and there aren't bootfiles in that origin anyway. When someday we can actually bootstrap upstream Chez Scheme, presumably we'll add a snippet to delete the pre-built bootfiles from the origin, at which point the it will still be the same origin for both. -Philip
Hi, Am Donnerstag, dem 17.02.2022 um 03:40 -0500 schrieb Philip McGrath: > Hi, > > On 2/17/22 03:19, Liliana Marie Prikler wrote: > > Hi, > > > > Am Donnerstag, dem 17.02.2022 um 03:06 -0500 schrieb Philip > > McGrath: > > > Hi, > > > > > > On 2/17/22 02:10, Liliana Marie Prikler wrote: > > > > [...] > > > > 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`? > > Yes. > > > > > What commonality is the function abstracting over, compared to > > > having > > > 'chez-scheme-for-racket-bootstrap-bootfiles' inherit from 'chez- > > > scheme-bootstrap-bootfiles'? > > At the moment version, source, home-page and license. I don't > > really > > think bootstrap files ought to be a part of chez' source, so if you > > wanted to do this really cleanly, you'd have to drop them from chez > > and > > add restrict chez-bootstrap to them, which would imply you'd have > > to > > use (version (package-version chez-scheme)) explicitly – for now I > > don't want to add too much burden to that patch and you can assume > > source to be the same between the two. > > > > Ok, this helps, I think. I'll give it a try. > > In <https://issues.guix.gnu.org/47153#9> you argued---and convinced > me---that we should keep the pre-built bootfiles in the origin until > we actually don't need them. With 'chez-scheme-for-racket', that's > already true, and there aren't bootfiles in that origin anyway. When > someday we can actually bootstrap upstream Chez Scheme, presumably > we'll add a snippet to delete the pre-built bootfiles from the > origin, at which point the it will still be the same origin for both. This concerns schez-scheme-for-racket, not the current chez-scheme for which we are packaging the bootfiles, am I right? Given that we build a set of bootfiles that would be enough to go forward, we no longer need the original bootfiles beyond that point, i.e. the "bootstrap bootfiles" would only be needed inside chez-bootstrap, but not chez itself (which can instead use the native-input). Am I missing something here?
diff --git a/gnu/packages/chez-and-racket-bootstrap.scm b/gnu/packages/chez-and-racket-bootstrap.scm index 90fd63b5ae..38708ab690 100644 --- a/gnu/packages/chez-and-racket-bootstrap.scm +++ b/gnu/packages/chez-and-racket-bootstrap.scm @@ -216,9 +216,9 @@ (define unpack-nanopass+stex ;; otherwise, it will try to download submodules (display "# to placate ../configure"))))) -(define-public chez-scheme +(define-public chez-scheme-bootstrap-bootfiles (package - (name "chez-scheme") + (name "chez-scheme-bootstrap-bootfiles") ;; The version should match `(scheme-version-number)`. ;; See s/cmacros.ss c. line 360. (version "9.5.6") @@ -230,8 +230,45 @@ (define-public chez-scheme (sha256 (base32 "07s433hn1z2slfc026sidrpzxv3a8narcd40qqr1xrpb9012xdky")) - (file-name (git-file-name name version)) + (file-name (git-file-name "chez-scheme" version)) (snippet unbundle-chez-submodules))) + (build-system copy-build-system) + ;; TODO: cross compilation + (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 ((mach (nix-system->chez-machine system #:threads? #f))) + (or (equal? "arm32le" mach) + (and mach + (member (substring mach 0 2) '("i3" "a6")) + (or-map (cut string-suffix? <> mach) + '("le" "nt" "osx")))))) + %supported-systems)) + (home-page "https://cisco.github.io/ChezScheme/") + (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.") + (properties `((hidden? . #t))) + (license license:asl2.0))) + +(define-public chez-scheme + (package + (name "chez-scheme") + (version (package-version chez-scheme-bootstrap-bootfiles)) + (source (package-source chez-scheme-bootstrap-bootfiles)) (build-system gnu-build-system) (inputs (list @@ -242,7 +279,9 @@ (define-public chez-scheme ;; for X11 clipboard support in expeditor: ;; https://github.com/cisco/ChezScheme/issues/9#issuecomment-222057232 libx11)) - (native-inputs (list chez-nanopass-bootstrap stex-bootstrap)) + (native-inputs (list chez-scheme-bootstrap-bootfiles + chez-nanopass-bootstrap + stex-bootstrap)) (native-search-paths (list (search-path-specification (variable "CHEZSCHEMELIBDIRS") @@ -263,6 +302,14 @@ (define-public chez-scheme (add-after 'unpack 'unpack-nanopass+stex (lambda args #$unpack-nanopass+stex)) + (add-after 'unpack-nanopass+stex 'unpack-bootfiles + (lambda* (#:key native-inputs inputs #:allow-other-keys) + (when (directory-exists? "boot") + (delete-file-recursively "boot")) + (copy-recursively + (search-input-directory (or native-inputs inputs) + "lib/chez-scheme-bootfiles") + "boot"))) ;; NOTE: the custom Chez 'configure' script doesn't allow ;; unrecognized flags, such as those automatically added ;; by `gnu-build-system`. @@ -345,7 +392,7 @@ (define* (stex-make #:optional (suffix "")) (not (eq? 'no-support (chez-machine->upstream-restriction mach)))))) %supported-systems))) - (home-page "https://cisco.github.io/ChezScheme/") + (home-page (package-home-page chez-scheme-bootstrap-bootfiles)) (synopsis "R6RS Scheme compiler and run-time") (description "Chez Scheme is a compiler and run-time system for the language of the