[PATCH] gnu: chez-scheme: simplify packaging

  • Done
  • quality assurance status badge
Details
3 participants
  • Leo Prikler
  • Ludovic Courtès
  • Philip McGrath
Owner
unassigned
Submitted by
Philip McGrath
Severity
normal
P
P
Philip McGrath wrote on 15 Mar 2021 09:42
(address . guix-patches@gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210315084235.7051-1-philip@philipmcgrath.com
Take advantage of patches that have been accepted upstream.
These changes lay a foundation for reusing more of Chez's
build process for Racket.

* gnu/packages/patches/chez-scheme-build-util-paths-backport.patch:
New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/chez.scm (nanopass): Rename it to ...
(nanopass-framework-scheme): ... this variable. Change it from an origin
to a package. Update to 1.9.2.
(stex): Rename it to ...
(chez-stex): ... this variable. Change it from an origin to a hidden
package. Update to commit 5405149, which helps us install it.
(chez-scheme)[source](patches): Use it.
[source](snippet): Remove bundled libraries here, not during 'configure'
phase. Also remove irrelevant bootfiles.
[inputs]: Organize. Move "nanopass" and "stex" to ...
[native-inputs]: ... this field.
[outputs]: Add "stex".
[arguments]: Remove #:configure-flags which were ignored. Add (ice-9 ftw)
to #:modules. Remove unneeded 'patch-processor-detection' phase.
Add 'link-nanopass+stex' phase (refactored from 'configure').
Simplify 'configure' phase by removing patches that have been upstreamed.
Detect when "--disable-curses" or "--disable-x11" flags are needed.
Add "--nogzip-man-pages" flag so we can remove 'make-manpages-writable'
phase. Refactor 'install-doc' phase into 'build+install-stex' and
'build+install-doc'
---
gnu/local.mk | 1 +
gnu/packages/chez.scm | 370 ++++++---
...hez-scheme-build-util-paths-backport.patch | 780 ++++++++++++++++++
3 files changed, 1030 insertions(+), 121 deletions(-)
create mode 100644 gnu/packages/patches/chez-scheme-build-util-paths-backport.patch

Toggle diff (398 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index 0954158d4c..96de2e108e 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -879,6 +879,7 @@ dist_patch_DATA = \
%D%/packages/patches/cdparanoia-fpic.patch \
%D%/packages/patches/cdrtools-3.01-mkisofs-isoinfo.patch \
%D%/packages/patches/ceph-disable-cpu-optimizations.patch \
+ %D%/packages/patches/chez-scheme-build-util-paths-backport.patch \
%D%/packages/patches/chmlib-inttypes.patch \
%D%/packages/patches/cl-asdf-config-directories.patch \
%D%/packages/patches/clamav-config-llvm-libs.patch \
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index eac556c4d0..e1e94bc90c 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2019 Brett Gilio <brettg@gnu.org>
;;; Copyright © 2020 Brendan Tildesley <mail@brendan.scot>
+;;; Copyright © 2021 Philip McGrath <philip@philipmcgrath.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -30,6 +31,7 @@
#:use-module (guix git-download)
#:use-module (guix utils)
#:use-module (guix build-system gnu)
+ #:use-module (guix gexp)
#:use-module (gnu packages compression)
#:use-module (gnu packages ncurses)
#:use-module (gnu packages ghostscript)
@@ -42,25 +44,103 @@
#:use-module (ice-9 match)
#:use-module (srfi srfi-1))
-(define nanopass
- (let ((version "1.9.1"))
- (origin
- (method git-fetch)
- (uri (git-reference
- (url "https://github.com/nanopass/nanopass-framework-scheme")
- (commit (string-append "v" version))))
- (sha256 (base32 "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
- (file-name (git-file-name "nanopass" version)))))
+;; Nanopass will be used by Racket and could be used by
+;; any of the supported Scheme implementations.
+;; Making it a package lets us do the unpacking
+;; and patching steps just once.
+(define-public nanopass-framework-scheme
+ (let ((version "1.9.2"))
+ (package
+ (name "nanopass-framework-scheme")
+ (version version)
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/nanopass/nanopass-framework-scheme")
+ (commit (string-append "v" version))))
+ (sha256 "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
+ (file-name (git-file-name "nanopass" version))))
+ (home-page "https://nanopass.org")
+ (synopsis
+ "Embeded domain-specific language for writing compiler passes")
+ (description
+ "The Nanopass Framework is an embedded domain-specific language
+for creating compilers that focuses on creating small passes and many
+intermediate representations. Nanopass reduces the boilerplate required to
+create compilers, making them easier to understand and maintain.
+
+This package contains the R6RS source distribution, which is known to work with
+Chez Scheme, Vicare Scheme, and Ikarus Scheme.")
+ (license (list expat))
+ (build-system gnu-build-system)
+ (arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (delete 'bootstrap)
+ (delete 'patch-usr-bin-file)
+ (delete 'configure)
+ (delete 'patch-generated-file-shebangs)
+ (delete 'build)
+ (delete 'check)
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (copy-recursively "." (assoc-ref outputs "out"))
+ #t))
+ (delete 'patch-shebangs)
+ (delete 'strip)
+ (delete 'validate-runpath)
+ (delete 'validate-documentation-location)
+ (delete 'delete-info-dir-file)
+ (delete 'patch-dot-desktop-files)
+ (delete 'install-license-files)
+ (delete 'reset-gzip-timestamps)
+ (delete 'compress-documentation)))))))
+
+
+(define chez-stex
+ ;; Hidden because of a circular dependency issue:
+ ;; stex needs chez-scheme to be used, but chez-scheme uses
+ ;; stex to build its documentation.
+ ;; The chez-scheme package has an stex output that exposes
+ ;; the useful version of this---or maybe there's a more elegant solution?
+ (hidden-package
+ (let ((version "1.2.2")
+ ;; This commit includes a fix for which we would
+ ;; otherwise want to use a snippet.
+ ;; When there's a new tagged release,
+ ;; go back to using (string-append "v" version)
+ (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")
+ (revision "1")) ;Guix package revision
+ (package
+ (inherit nanopass-framework-scheme)
+ (name "chez-stex")
+ (version (git-version version revision commit))
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/dybvig/stex")
+ (commit commit)))
+ (sha256 "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
+ (file-name (git-file-name "stex" version))))
+ (home-page "https://github.com/dybvig/stex")
+ (synopsis
+ "Tools for including Scheme in LaTeX and converting to HTML")
+ (description
+ "The @dfn{stex} package consists of two main programs and some
+supporting items, such as make files, make-file templates, class files,
+and style files. The two main programs are @command{scheme-prep} and
+@command{html-prep}. @command{scheme-prep} performs a conversion from
+stex-formatted files into LaTeX-formatted files, while @command{html-prep}
+converts (some) LaTeX-formatted files into html-formatted files.
+
+An stex file is really just a LaTeX file extended with a handful of commands
+for including Scheme code (or pretty much any other kind of code, as long as
+you don't plan to use the Scheme-specific transcript support) in a document,
+plus a couple of additional features rather arbitrarily thrown in.")
+ (license (list expat))))))
-(define stex
- (let ((version "1.2.2"))
- (origin
- (method git-fetch)
- (uri (git-reference
- (url "https://github.com/dybvig/stex")
- (commit (string-append "v" version))))
- (sha256 (base32 "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
- (file-name (git-file-name "stex" version)))))
(define-public chez-scheme
(package
@@ -74,21 +154,49 @@
(commit (string-append "v" version))))
(sha256
(base32 "0prgn2z9l888j93ydxaf04ph424g0fi3a8w7f8m0b2r7fr1v7388"))
- (file-name (git-file-name name version))))
+ (file-name (git-file-name name version))
+ (patches
+ (search-patches
+ ;; backported from upstream: remove on next release
+ "chez-scheme-build-util-paths-backport.patch"))
+ (snippet
+ ;; remove bundled libraries
+ (with-imported-modules '((guix build utils))
+ #~(begin
+ (use-modules (guix build utils))
+ (for-each (lambda (dir)
+ (when (directory-exists? dir)
+ (delete-file-recursively dir)))
+ '("stex"
+ "nanopass"
+ "lz4"
+ "zlib"
+ ;; pre-built bootfiles for unsupported systems:
+ "boot/a6nt"
+ "boot/a6osx"
+ "boot/i3nt"
+ "boot/i3osx"
+ "boot/ta6nt"
+ "boot/ta6osx"
+ "boot/ti3nt"
+ "boot/ti3osx")))))))
(build-system gnu-build-system)
(inputs
- `(("ncurses" ,ncurses)
- ("libuuid" ,util-linux "lib")
- ("libx11" ,libx11)
- ("lz4" ,lz4)
- ("lz4:static" ,lz4 "static")
- ("xorg-rgb" ,xorg-rgb)
- ("nanopass" ,nanopass)
+ `(("libuuid" ,util-linux "lib")
("zlib" ,zlib)
("zlib:static" ,zlib "static")
- ("stex" ,stex)))
+ ("lz4" ,lz4)
+ ("lz4:static" ,lz4 "static")
+ ;; for expeditor:
+ ("ncurses" ,ncurses)
+ ;; for X:
+ ("libx11" ,libx11)
+ ("xorg-rgb" ,xorg-rgb)))
(native-inputs
- `(("texlive" ,(texlive-union (list texlive-latex-oberdiek
+ `(("nanopass" ,nanopass-framework-scheme) ; source-only distribution
+ ;; for docs
+ ("stex" ,chez-stex)
+ ("texlive" ,(texlive-union (list texlive-latex-oberdiek
texlive-generic-epsf)))
("ghostscript" ,ghostscript)
("netpbm" ,netpbm)))
@@ -96,98 +204,63 @@
(list (search-path-specification
(variable "CHEZSCHEMELIBDIRS")
(files (list (string-append "lib/csv" version "-site"))))))
- (outputs '("out" "doc"))
+ (outputs '("out" "stex" "doc"))
(arguments
- `(#:modules ((guix build gnu-build-system)
- (guix build utils)
- (ice-9 match))
+ `(#:modules
+ ((guix build gnu-build-system)
+ (guix build utils)
+ (ice-9 ftw)
+ (ice-9 match))
#:test-target "test"
- #:configure-flags
- (list ,(match (or (%current-target-system) (%current-system))
- ("x86_64-linux" '(list "--machine=ta6le"))
- ("i686-linux" '(list "--machine=ti3le"))
- ;; Let autodetection have its attempt on other architectures.
- (_
- '())))
#:phases
(modify-phases %standard-phases
- (add-after 'unpack 'patch-processor-detection
- (lambda _ (substitute* "configure"
- (("uname -a") "uname -m"))
- #t))
- ;; Adapt the custom 'configure' script.
+ ;; put these where configure expects them to be
+ (add-after 'unpack 'link-nanopass+stex
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (symlink (assoc-ref (or native-inputs inputs) "nanopass")
+ "nanopass")
+ (let ((stex-src (assoc-ref (or native-inputs inputs) "stex")))
+ ;; making stex wants to create a build directory,
+ ;; so the immediate directory must be writable
+ (mkdir "stex")
+ (with-directory-excursion "stex"
+ (for-each (lambda (pth)
+ (unless (member pth '("." ".."))
+ (symlink (string-append stex-src "/" pth)
+ pth)))
+ (scandir stex-src))))
+ #t))
+ ;; NOTE: the custom Chez 'configure' script doesn't allow
+ ;; unrecognized flags, such as those automatically added
+ ;; by `gnu-build-system`.
(replace 'configure
(lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out"))
- (nanopass (assoc-ref inputs "nanopass"))
- (stex (assoc-ref inputs "stex"))
- (lz4-static (assoc-ref inputs "lz4:static"))
- (zlib-static (assoc-ref inputs "zlib:static"))
- (unpack (assoc-ref %standard-phases 'unpack))
- (patch-source-shebangs
- (assoc-ref %standard-phases 'patch-source-shebangs)))
- (map (match-lambda
- ((src orig-name new-name)
- (with-directory-excursion "."
- (apply unpack (list #:source src))
- (apply patch-source-shebangs (list #:source src)))
- (delete-file-recursively new-name)
- (invoke "mv" orig-name new-name)))
- `((,nanopass "source" "nanopass")
- (,stex "source" "stex")))
- ;; The configure step wants to CURL all submodules as it
- ;; detects a checkout without submodules. Disable curling,
- ;; and manually patch the needed modules for compilation.
- (substitute* "configure"
- (("! -f '") "-d '")) ; working around CURL.
- (substitute* (find-files "mats" "Mf-.*")
- (("^[[:space:]]+(cc ) *") "\tgcc "))
- (substitute*
- (find-files "." (string-append
- "("
- "Mf-[a-zA-Z0-9.]+"
- "|Makefile[a-zA-Z0-9.]*"
- "|checkin"
- "|stex\\.stex"
- "|newrelease"
- "|workarea"
- "|unix\\.ms"
- "|^6\\.ms"
- ;;"|[a-zA-Z0-9.]+\\.ms" ; guile can't read
- ")"))
- (("/bin/rm") (which "rm"))
- (("/bin/ln") (which "ln"))
- (("/bin/cp") (which "cp"))
- (("/bin/echo") (which "echo")))
- (substitute* "makefiles/installsh"
- (("/bin/true") (which "true")))
- (substitute* "stex/Makefile"
- (("PREFIX=/usr") (string-append "PREFIX=" out)))
- (invoke "./configure" "--threads"
- (string-append "ZLIB=" zlib-static "/lib/libz.a")
- (string-append "LZ4=" lz4-static "/lib/liblz4.a")
- (string-append "--installprefix=" out)))))
- ;; Installation of the documentation requires a running "chez".
- (add-after 'install 'install-doc
- (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((doc (string-append (assoc-ref outputs "doc")
- "/share/doc/" ,name "-" ,version)))
- (invoke "make" "docs")
- (with-directory-excursion "csug"
- (substitute* "Makefile"
- ;; The ‘installdir=’ can't be overruled on the command line.
- (("/tmp/csug9") doc)
- ;; $m is the ‘machine type’, e.g. ‘ta6le’ on x86_64, but is
- ;; set incorrectly for some reason, e.g. to ‘a6le’ on x86_64.
- ;; Avoid the whole mess by running the (machine-independent)
- ;; ‘installsh’ script at its original location.
- (("\\$m/installsh") "makefiles/installsh"))
- (invoke "make" "install")
- (install-file "csug.pdf" doc))
- (with-directory-excursion "release_notes"
- (install-file "release_notes.pdf" doc))
+ (let* ((zlib-static (assoc-ref inputs "zlib:static"))
+ (lz4-static (assoc-ref inputs "lz4:static"))
+ (out (assoc-ref outputs "out"))
+ (flags (list
+ (string-append "--installprefix=" out)
+ (string-append "ZLIB=" zlib-static "/lib/libz.a")
+ (string-append "LZ4=" lz4-static "/lib/liblz4.a")
+ "--nogzip-man-pages" ;; guix will do it
+ "--threads"))
+ (flags (if (assoc-ref inputs "ncurses")
+ flags
+ (cons "--disable-curses"
+ flags)))
+ (flags (if (and (assoc-ref inputs "libx11")
+ (assoc-ref inputs "xorg-rgb"))
+ flags
+ (cons "--disable-x11"
+ flags))))
+ ;; Some makefiles (for tests) don't seem to propagate CC
+ ;; properly, so we take it out of their hands:
+ (setenv "CC" "gcc")
+ (apply invoke
+ "./configure"
+ flags)
#t)))
- ;; The binary file name is called "scheme" as the one from MIT/GNU
+ ;; The binary file name is called "scheme" as is the one from MIT/GNU
;; Scheme. We add a symlink to use in case both are installed.
(add-after 'install 'install-symlink
(lambda* (#:key outputs #:allow-other-keys)
@@ -202,16 +275,70 @@
"/" name ".boot")))
(find-files lib "scheme.boot"))
#t)))
- (add-before 'reset-gzip-timestamps 'make-manpages-writable
- (lambda* (#:key outputs #:allow-other-keys)
- (map (lambda (file)
- (make-file-writable file))
- (find-files (string-append (assoc-ref outputs "out")
- "/share/man")
- ".*\\.gz$"))
- #t)))))
+ ;; We build & install stex so it can (in principle)
+ ;; be reused for other documents.
+ (add-after 'install-symlink 'build+install-stex
+ (lambda* (#:key native-inputs inputs outputs #:allow-other-keys)
+ (let* ((stex+version
+ (strip-store-file-name
+ (assoc-ref (or native-inputs inputs) "stex")))
+ (stex-output (assoc-ref outputs "stex"))
+ (doc-dir (string-append stex-output
+ "/share/doc/"
+ stex+version)))
+ (with-directory-excursion "stex"
+ (invoke "make"
+ "install"
+ (string-append "LIB="
+ stex-output
+ "/lib/"
+ stex+version)
+ (string-append "Scheme="
+ (assoc-ref outputs "out")
+ "/bin/scheme"))
+ (for-each (lambda (pth)
+
This message was truncated. Download the full message here.
L
L
Leo Prikler wrote on 15 Mar 2021 11:32
cd84e81c9636899b80ef3e31fd0fbb2bd23de7ad.camel@student.tugraz.at
Hi,

I'm not an expert on Chez Scheme, so take this with a grain of salt,
but I do have some questions/remarks.

Am Montag, den 15.03.2021, 04:42 -0400 schrieb Philip McGrath:
Toggle quote (4 lines)
> * gnu/packages/chez.scm (nanopass): Rename it to ...
> (nanopass-framework-scheme): ... this variable. Change it from an
> origin
> to a package. Update to 1.9.2.
What advantages do we get from making this a package? Can it be
upgraded to 1.9.2 without this change at the same time?
Toggle quote (3 lines)
> (stex): Rename it to ...
> (chez-stex): ... this variable. Change it from an origin to a hidden
> package. Update to commit 5405149, which helps us install it.
Same here, also does this need to be done at the same time as the
nanopass upgrade?
Toggle quote (1 lines)
> (chez-scheme)[source](patches): Use it.
Use what?
Toggle quote (3 lines)
> [source](snippet): Remove bundled libraries here, not during
> 'configure'
> phase. Also remove irrelevant bootfiles.
This seems okay.
Toggle quote (23 lines)
> + (build-system gnu-build-system)
> + (arguments
> + `(#:phases
> + (modify-phases %standard-phases
> + (delete 'bootstrap)
> + (delete 'patch-usr-bin-file)
> + (delete 'configure)
> + (delete 'patch-generated-file-shebangs)
> + (delete 'build)
> + (delete 'check)
> + (replace 'install
> + (lambda* (#:key outputs #:allow-other-keys)
> + (copy-recursively "." (assoc-ref outputs "out"))
> + #t))
> + (delete 'patch-shebangs)
> + (delete 'strip)
> + (delete 'validate-runpath)
> + (delete 'validate-documentation-location)
> + (delete 'delete-info-dir-file)
> + (delete 'patch-dot-desktop-files)
> + (delete 'install-license-files)
> + (delete 'reset-gzip-timestamps)
> + (delete 'compress-documentation)))))))
copy-build-system exists. And again, what is the point of making this
a package if it contains the exact same files as the corresponding
origin?

Toggle quote (64 lines)
> +(define chez-stex
> + ;; Hidden because of a circular dependency issue:
> + ;; stex needs chez-scheme to be used, but chez-scheme uses
> + ;; stex to build its documentation.
> + ;; The chez-scheme package has an stex output that exposes
> + ;; the useful version of this---or maybe there's a more elegant
> solution?
> + (hidden-package
> + (let ((version "1.2.2")
> + ;; This commit includes a fix for which we would
> + ;; otherwise want to use a snippet.
> + ;; When there's a new tagged release,
> + ;; go back to using (string-append "v" version)
> + (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")
> + (revision "1")) ;Guix package revision
> + (package
> + (inherit nanopass-framework-scheme)
> + (name "chez-stex")
> + (version (git-version version revision commit))
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/dybvig/stex")
> + (commit commit)))
> + (sha256
> "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
> + (file-name (git-file-name "stex" version))))
> + (home-page "https://github.com/dybvig/stex")
> + (synopsis
> + "Tools for including Scheme in LaTeX and converting to
> HTML")
> + (description
> + "The @dfn{stex} package consists of two main programs and
> some
> +supporting items, such as make files, make-file templates, class
> files,
> +and style files. The two main programs are @command{scheme-prep}
> and
> +@command{html-prep}. @command{scheme-prep} performs a conversion
> from
> +stex-formatted files into LaTeX-formatted files, while
> @command{html-prep}
> +converts (some) LaTeX-formatted files into html-formatted files.
> +
> +An stex file is really just a LaTeX file extended with a handful of
> commands
> +for including Scheme code (or pretty much any other kind of code, as
> long as
> +you don't plan to use the Scheme-specific transcript support) in a
> document,
> +plus a couple of additional features rather arbitrarily thrown in.")
> + (license (list expat))))))
>
> -(define stex
> - (let ((version "1.2.2"))
> - (origin
> - (method git-fetch)
> - (uri (git-reference
> - (url "https://github.com/dybvig/stex")
> - (commit (string-append "v" version))))
> - (sha256 (base32
> "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
> - (file-name (git-file-name "stex" version)))))
Again, where is the benefit in having this as a hidden-package?

Regards,
Leo
P
P
Philip McGrath wrote on 15 Mar 2021 19:03
80ae553f-ac34-9b63-af43-9adf7d7113a6@philipmcgrath.com
Hi!

On 3/15/21 6:32 AM, Leo Prikler wrote:
Toggle quote (2 lines)
> I'm not an expert on Chez Scheme, so take this with a grain of salt,

I'm not an expert on Guix, so take this with a grain of salt :)

I've been exploring packaging for Racket, and, by extension, Chez
Scheme, as a way to get more familiar with Guix.

Toggle quote (12 lines)
> Am Montag, den 15.03.2021, 04:42 -0400 schrieb Philip McGrath:
>> * gnu/packages/chez.scm (nanopass): Rename it to ...
>> (nanopass-framework-scheme): ... this variable. Change it from an
>> origin
>> to a package. Update to 1.9.2.
> What advantages do we get from making this a package? Can it be
> upgraded to 1.9.2 without this change at the same time?
>> (stex): Rename it to ...
>> (chez-stex): ... this variable. Change it from an origin to a hidden
>> package. Update to commit 5405149, which helps us install it.
> Same here

I don't have a strong opinion about whether these should be packages. My
main goal was to have the unpack and patch-source-shebangs phases happen
just once, rather than be handled in an ad-hoc way inside chez-scheme's
configure phase, because I know I will be reusing these in the Racket
package, as well.

There are some other considerations specific to each package/origin:

- nanopass-framework-scheme is portable to many R6RS Scheme
implementations. It doesn't have a Makefile or anything:
you just put it in the right place and then happily
`(import (nanopass))` from your Scheme of choice.

- I think the right thing would be to make chez-stex a
public package, instead of the "stex" output of the chez-scheme
package, but there are some bootstrapping issues I'll discuss below.


Toggle quote (3 lines)
> , also does this need to be done at the same time as the
> nanopass upgrade?

No

Toggle quote (3 lines)
>> (chez-scheme)[source](patches): Use it.
> Use what?

The new patch chez-scheme-build-util-paths-backport.patch added above.
Is there a better way to write that in the message?

Toggle quote (4 lines)
> copy-build-system exists. And again, what is the point of making this
> a package if it contains the exact same files as the corresponding
> origin?

copy-build-system also does validate-documentation-location and
install-license-files, IIUC. But again, I'm open to alternative approaches.

Toggle quote (8 lines)
>> +(define chez-stex
>> + ;; Hidden because of a circular dependency issue:
>> + ;; stex needs chez-scheme to be used, but chez-scheme uses
>> + ;; stex to build its documentation.
>> + ;; The chez-scheme package has an stex output that exposes
>> + ;; the useful version of this---or maybe there's a more elegant
>> solution?

This is related to the comments I added about things probably being
wrong for cross-compilation, though I don't think they're any more wrong
with this patch than without it. Fundamentally, you need Chez Scheme to
compile Chez Scheme. (The Racket fork can be bootstrapped with a C-based
Racket implementation that simulates enough of Chez Scheme to compile
the Chez Scheme compiler. Unfortunately, the forks have diverged too
much right now, at a minimum in the definition of `#!base-rtd`, to be
able to bootstrap upstream Chez that way.)

Chez distributes "bootfiles" for i686, x86_64, and "arm32" (which I
hope, but am not sure, could work for "armhf"). Once you've done a
native build for one of those platforms, you can use it to cross-compile
for any platform Chez Scheme supports (ppc32, various BSDs, etc—Racket's
fork adds arm64, and there's been some work on riscv). You need Chez to
build stex, and thus you need a native Chez to build the Chez Scheme docs.

I'm not sure what the best way to structure that in Guix would be. Maybe
a hidden variant of Chez that builds the public Chez?

Suggestions are very welcome!

-Philip
L
L
Leo Prikler wrote on 15 Mar 2021 19:28
c8b7f1cc029f72e77e728a0a3997456b0155895f.camel@student.tugraz.at
Hi!

Am Montag, den 15.03.2021, 14:03 -0400 schrieb Philip McGrath:
Toggle quote (10 lines)
> Hi!
>
> On 3/15/21 6:32 AM, Leo Prikler wrote:
> > I'm not an expert on Chez Scheme, so take this with a grain of
> > salt,
>
> I'm not an expert on Guix, so take this with a grain of salt :)
>
> I've been exploring packaging for Racket, and, by extension, Chez
> Scheme, as a way to get more familiar with Guix.
Hehe, I see what you did there ?

Toggle quote (22 lines)
> > Am Montag, den 15.03.2021, 04:42 -0400 schrieb Philip McGrath:
> > > * gnu/packages/chez.scm (nanopass): Rename it to ...
> > > (nanopass-framework-scheme): ... this variable. Change it from an
> > > origin
> > > to a package. Update to 1.9.2.
> > What advantages do we get from making this a package? Can it be
> > upgraded to 1.9.2 without this change at the same time?
> > > (stex): Rename it to ...
> > > (chez-stex): ... this variable. Change it from an origin to a
> > > hidden
> > > package. Update to commit 5405149, which helps us install it.
> > Same here
>
> I don't have a strong opinion about whether these should be packages.
> My
> main goal was to have the unpack and patch-source-shebangs phases
> happen
> just once, rather than be handled in an ad-hoc way inside chez-
> scheme's
> configure phase, because I know I will be reusing these in the
> Racket
> package, as well.
I think your worries might be a little unfounded; adding more phases
between unpack and patch-source-shebangs to add additional sources
might not be the most common pattern in Guix, but it's certainly not a
rare one either. If you've ever played a trading card game, you might
call it "uncommon" ?

Toggle quote (6 lines)
> There are some other considerations specific to each package/origin:
>
> - nanopass-framework-scheme is portable to many R6RS Scheme
> implementations. It doesn't have a Makefile or anything:
> you just put it in the right place and then happily
> `(import (nanopass))` from your Scheme of choice.
Which makes even more sense to have it as origin. Suppose you were to
actually bytecompile it with both say Guile and Racket, then you'd have
a guile-nanopass and a racket-nanopass both with the same origin.

Toggle quote (3 lines)
> - I think the right thing would be to make chez-stex a
> public package, instead of the "stex" output of the chez-scheme
> package, but there are some bootstrapping issues I'll discuss below.
I agree. You can use the origin as an input to chez, like we've done
before, then use the already built chez to compile stex into chez-stex.
I don't think the latter half needs to be done right now, though, you
can delay that until you feel more experienced in packaging.

Toggle quote (4 lines)
> > , also does this need to be done at the same time as the
> > nanopass upgrade?
>
> No
Then you should separate this into more than one patch.

Toggle quote (6 lines)
> > > (chez-scheme)[source](patches): Use it.
> > Use what?
>
> The new patch chez-scheme-build-util-paths-backport.patch added
> above.
> Is there a better way to write that in the message?
It is not clear, since you've mixed up 3(+?) patches into one. Yet
another argument for separating your patches ?

Toggle quote (8 lines)
> > copy-build-system exists. And again, what is the point of making
> > this
> > a package if it contains the exact same files as the corresponding
> > origin?
>
> copy-build-system also does validate-documentation-location and
> install-license-files, IIUC. But again, I'm open to alternative
> approaches.
Since I don't really see the point in making it a package anyway, you
can keep it as an origin imo.

Toggle quote (32 lines)
> > > +(define chez-stex
> > > + ;; Hidden because of a circular dependency issue:
> > > + ;; stex needs chez-scheme to be used, but chez-scheme uses
> > > + ;; stex to build its documentation.
> > > + ;; The chez-scheme package has an stex output that exposes
> > > + ;; the useful version of this---or maybe there's a more elegant
> > > solution?
>
> This is related to the comments I added about things probably being
> wrong for cross-compilation, though I don't think they're any more
> wrong
> with this patch than without it. Fundamentally, you need Chez Scheme
> to
> compile Chez Scheme. (The Racket fork can be bootstrapped with a C-
> based
> Racket implementation that simulates enough of Chez Scheme to
> compile
> the Chez Scheme compiler. Unfortunately, the forks have diverged too
> much right now, at a minimum in the definition of `#!base-rtd`, to
> be
> able to bootstrap upstream Chez that way.)
>
> Chez distributes "bootfiles" for i686, x86_64, and "arm32" (which I
> hope, but am not sure, could work for "armhf"). Once you've done a
> native build for one of those platforms, you can use it to cross-
> compile
> for any platform Chez Scheme supports (ppc32, various BSDs,
> etc—Racket's
> fork adds arm64, and there's been some work on riscv). You need Chez
> to
> build stex, and thus you need a native Chez to build the Chez Scheme
> docs.
The way this would typically be solved in Guix would be to first build
a "minimal" variant of Chez without documentation, then use that to
build the full one. See also glib as an example, where such a
situation occurs. And yes, unless there is a good reason not to, the
minimal variant would be hidden. Calling back to your earlier
definition of chez-stex, you could use chez-minimal to compile the
(publicly exported) chez-stex package.

Regards,
Leo
P
P
Philip McGrath wrote on 15 Mar 2021 22:53
ae6c7828-1e40-10fb-7a0f-b279989f416e@philipmcgrath.com
Hi,

On 3/15/21 2:28 PM, Leo Prikler wrote:
Toggle quote (2 lines)
> Then you should separate this into more than one patch.

Ok, I've split this into three patches and kept nanopass and stex as
origins. Is it preferred to send them here or to start a new thread?

Toggle quote (8 lines)
>> - I think the right thing would be to make chez-stex a
>> public package, instead of the "stex" output of the chez-scheme
>> package, but there are some bootstrapping issues I'll discuss below.
> I agree. You can use the origin as an input to chez, like we've done
> before, then use the already built chez to compile stex into chez-stex.
> I don't think the latter half needs to be done right now, though, you
> can delay that until you feel more experienced in packaging.

I think I understand (most of) how to do this, but I think I'll put it
off for now and see how it interacts with my Racket plans. Maybe there
will be a more elegant bootstrapping solution.

-Philip
L
L
Leo Prikler wrote on 15 Mar 2021 23:21
9581850ed011d311db0388fcda41f8fbcd479730.camel@student.tugraz.at
Am Montag, den 15.03.2021, 17:53 -0400 schrieb Philip McGrath:
Toggle quote (8 lines)
> Hi,
>
> On 3/15/21 2:28 PM, Leo Prikler wrote:
> > Then you should separate this into more than one patch.
>
> Ok, I've split this into three patches and kept nanopass and stex as
> origins. Is it preferred to send them here or to start a new thread?

The preferred way is to use `git send-email --reroll-count=N` (in this
case N=2, afterwards counting up). I would also ask you to do a
rebasing pull before sending emails and perhaps fix up some whitespace
issues. v1 failed to apply on cbaines' patchwork[1] with the following
(see also [2]):

error: patch failed: gnu/local.mk:879
error: gnu/local.mk: patch does not apply


Toggle quote (13 lines)
> > > - I think the right thing would be to make chez-stex a
> > > public package, instead of the "stex" output of the chez-scheme
> > > package, but there are some bootstrapping issues I'll discuss
> > > below.
> > I agree. You can use the origin as an input to chez, like we've
> > done
> > before, then use the already built chez to compile stex into chez-
> > stex.
> > I don't think the latter half needs to be done right now, though,
> > you
> > can delay that until you feel more experienced in packaging.
>
> I think I understand (most of) how to do this
That's great!

Toggle quote (3 lines)
> I think I'll put it off for now and see how it interacts with my
> Racket plans. Maybe there will be a more elegant bootstrapping
> solution.
Indeed, simpler patch sets are much appreciated.

Regards,
Leo

P
P
Philip McGrath wrote on 15 Mar 2021 23:53
[PATCH v2 1/3] gnu: chez-scheme: Update nanopass to 1.9.2.
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210315225302.6597-1-philip@philipmcgrath.com
* gnu/packages/chez.scm (nanopass): Update nanopass to 1.9.2.
---
gnu/packages/chez.scm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

Toggle diff (30 lines)
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index eac556c4d0..5dd1185c43 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2019 Brett Gilio <brettg@gnu.org>
;;; Copyright © 2020 Brendan Tildesley <mail@brendan.scot>
+;;; Copyright © 2021 Philip McGrath <philip@philipmcgrath.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -43,13 +44,13 @@
#:use-module (srfi srfi-1))
(define nanopass
- (let ((version "1.9.1"))
+ (let ((version "1.9.2"))
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/nanopass/nanopass-framework-scheme")
(commit (string-append "v" version))))
- (sha256 (base32 "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
+ (sha256 "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
(file-name (git-file-name "nanopass" version)))))
(define stex
--
2.21.1 (Apple Git-122.3)
P
P
Philip McGrath wrote on 15 Mar 2021 23:53
[PATCH v2 2/3] gnu: chez-scheme: Update stex.
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210315225302.6597-2-philip@philipmcgrath.com
Get a patch from upstream that will help us simplify the build process
for the Chez Scheme documentation.

* gnu/packages/chez.scm (chez-stex): Update to commit 5405149.
---
gnu/packages/chez.scm | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index 5dd1185c43..dd0db04d88 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -59,8 +59,12 @@
(method git-fetch)
(uri (git-reference
(url "https://github.com/dybvig/stex")
- (commit (string-append "v" version))))
- (sha256 (base32 "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
+ ;; This commit includes a fix for which we would
+ ;; otherwise want to use a snippet.
+ ;; When there's a new tagged release,
+ ;; go back to using (string-append "v" version)
+ (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
+ (sha256 "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
(file-name (git-file-name "stex" version)))))
(define-public chez-scheme
--
2.21.1 (Apple Git-122.3)
P
P
Philip McGrath wrote on 15 Mar 2021 23:53
[PATCH v2 3/3] gnu: chez-scheme: simplify packaging
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210315225302.6597-3-philip@philipmcgrath.com
Take advantage of patches that have been accepted upstream.
These changes lay a foundation for reusing more of Chez's
build process for Racket.

* gnu/packages/patches/chez-scheme-build-util-paths-backport.patch:
New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/chez.scm (chez-scheme)[source](patches): Use it.
[source](snippet): Remove bundled libraries here, not during 'configure'
phase. Also remove irrelevant bootfiles.
[inputs]: Organize. Move "nanopass", "stex", and "xorg-rgb" to ...
[native-inputs]: ... this field.
[outputs]: Add "stex".
[arguments]: Remove #:configure-flags which were ignored. Add (ice-9 ftw)
to #:modules. Remove unneeded 'patch-processor-detection' phase.
Add 'unpack-nanopass+stex' phase (refactored from 'configure').
Simplify 'configure' phase by removing patches that have been upstreamed.
Detect when "--disable-curses" or "--disable-x11" flags are needed.
Add "--nogzip-man-pages" flag so we can remove 'make-manpages-writable'
phase. Refactor 'install-doc' phase into 'build+install-stex' and
'build+install-doc'
---
gnu/local.mk | 1 +
gnu/packages/chez.scm | 253 +++---
...hez-scheme-build-util-paths-backport.patch | 780 ++++++++++++++++++
3 files changed, 932 insertions(+), 102 deletions(-)
create mode 100644 gnu/packages/patches/chez-scheme-build-util-paths-backport.patch

Toggle diff (392 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index cf8849cf59..81b00f12a6 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -886,6 +886,7 @@ dist_patch_DATA = \
%D%/packages/patches/cdrtools-3.01-mkisofs-isoinfo.patch \
%D%/packages/patches/ceph-disable-cpu-optimizations.patch \
%D%/packages/patches/cgal-security-pr-5371.patch \
+ %D%/packages/patches/chez-scheme-build-util-paths-backport.patch \
%D%/packages/patches/chmlib-inttypes.patch \
%D%/packages/patches/cl-asdf-config-directories.patch \
%D%/packages/patches/clamav-config-llvm-libs.patch \
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index dd0db04d88..1ba7bc9ff3 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -30,6 +30,7 @@
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix utils)
+ #:use-module (guix gexp)
#:use-module (guix build-system gnu)
#:use-module (gnu packages compression)
#:use-module (gnu packages ncurses)
@@ -79,21 +80,49 @@
(commit (string-append "v" version))))
(sha256
(base32 "0prgn2z9l888j93ydxaf04ph424g0fi3a8w7f8m0b2r7fr1v7388"))
- (file-name (git-file-name name version))))
+ (file-name (git-file-name name version))
+ (patches
+ (search-patches
+ ;; backported from upstream: remove on next release
+ "chez-scheme-build-util-paths-backport.patch"))
+ (snippet
+ ;; remove bundled libraries
+ (with-imported-modules '((guix build utils))
+ #~(begin
+ (use-modules (guix build utils))
+ (for-each (lambda (dir)
+ (when (directory-exists? dir)
+ (delete-file-recursively dir)))
+ '("stex"
+ "nanopass"
+ "lz4"
+ "zlib"
+ ;; pre-built bootfiles for unsupported systems:
+ "boot/a6nt"
+ "boot/a6osx"
+ "boot/i3nt"
+ "boot/i3osx"
+ "boot/ta6nt"
+ "boot/ta6osx"
+ "boot/ti3nt"
+ "boot/ti3osx")))))))
(build-system gnu-build-system)
(inputs
- `(("ncurses" ,ncurses)
- ("libuuid" ,util-linux "lib")
- ("libx11" ,libx11)
- ("lz4" ,lz4)
- ("lz4:static" ,lz4 "static")
- ("xorg-rgb" ,xorg-rgb)
- ("nanopass" ,nanopass)
+ `(("libuuid" ,util-linux "lib")
("zlib" ,zlib)
("zlib:static" ,zlib "static")
- ("stex" ,stex)))
+ ("lz4" ,lz4)
+ ("lz4:static" ,lz4 "static")
+ ;; for expeditor:
+ ("ncurses" ,ncurses)
+ ;; for X11 clipboard support in expeditor:
+ ("libx11" ,libx11)))
(native-inputs
- `(("texlive" ,(texlive-union (list texlive-latex-oberdiek
+ `(("nanopass" ,nanopass) ; source only
+ ;; for docs
+ ("stex" ,stex)
+ ("xorg-rgb" ,xorg-rgb)
+ ("texlive" ,(texlive-union (list texlive-latex-oberdiek
texlive-generic-epsf)))
("ghostscript" ,ghostscript)
("netpbm" ,netpbm)))
@@ -103,96 +132,58 @@
(files (list (string-append "lib/csv" version "-site"))))))
(outputs '("out" "doc"))
(arguments
- `(#:modules ((guix build gnu-build-system)
- (guix build utils)
- (ice-9 match))
+ `(#:modules
+ ((guix build gnu-build-system)
+ (guix build utils)
+ (ice-9 ftw)
+ (ice-9 match))
#:test-target "test"
- #:configure-flags
- (list ,(match (or (%current-target-system) (%current-system))
- ("x86_64-linux" '(list "--machine=ta6le"))
- ("i686-linux" '(list "--machine=ti3le"))
- ;; Let autodetection have its attempt on other architectures.
- (_
- '())))
#:phases
(modify-phases %standard-phases
- (add-after 'unpack 'patch-processor-detection
- (lambda _ (substitute* "configure"
- (("uname -a") "uname -m"))
- #t))
- ;; Adapt the custom 'configure' script.
- (replace 'configure
- (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out"))
- (nanopass (assoc-ref inputs "nanopass"))
- (stex (assoc-ref inputs "stex"))
- (lz4-static (assoc-ref inputs "lz4:static"))
- (zlib-static (assoc-ref inputs "zlib:static"))
- (unpack (assoc-ref %standard-phases 'unpack))
- (patch-source-shebangs
+ ;; put these where configure expects them to be
+ (add-after 'unpack 'unpack-nanopass+stex
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (let ((patch-source-shebangs
(assoc-ref %standard-phases 'patch-source-shebangs)))
- (map (match-lambda
- ((src orig-name new-name)
- (with-directory-excursion "."
- (apply unpack (list #:source src))
- (apply patch-source-shebangs (list #:source src)))
- (delete-file-recursively new-name)
- (invoke "mv" orig-name new-name)))
- `((,nanopass "source" "nanopass")
- (,stex "source" "stex")))
- ;; The configure step wants to CURL all submodules as it
- ;; detects a checkout without submodules. Disable curling,
- ;; and manually patch the needed modules for compilation.
- (substitute* "configure"
- (("! -f '") "-d '")) ; working around CURL.
- (substitute* (find-files "mats" "Mf-.*")
- (("^[[:space:]]+(cc ) *") "\tgcc "))
- (substitute*
- (find-files "." (string-append
- "("
- "Mf-[a-zA-Z0-9.]+"
- "|Makefile[a-zA-Z0-9.]*"
- "|checkin"
- "|stex\\.stex"
- "|newrelease"
- "|workarea"
- "|unix\\.ms"
- "|^6\\.ms"
- ;;"|[a-zA-Z0-9.]+\\.ms" ; guile can't read
- ")"))
- (("/bin/rm") (which "rm"))
- (("/bin/ln") (which "ln"))
- (("/bin/cp") (which "cp"))
- (("/bin/echo") (which "echo")))
- (substitute* "makefiles/installsh"
- (("/bin/true") (which "true")))
- (substitute* "stex/Makefile"
- (("PREFIX=/usr") (string-append "PREFIX=" out)))
- (invoke "./configure" "--threads"
- (string-append "ZLIB=" zlib-static "/lib/libz.a")
- (string-append "LZ4=" lz4-static "/lib/liblz4.a")
- (string-append "--installprefix=" out)))))
- ;; Installation of the documentation requires a running "chez".
- (add-after 'install 'install-doc
+ (for-each (lambda (dep)
+ (define src
+ (assoc-ref (or native-inputs inputs) dep))
+ (copy-recursively src dep
+ #:keep-mtime? #t)
+ (with-directory-excursion dep
+ (patch-source-shebangs #:source src)))
+ '("nanopass" "stex"))
+ #t)))
+ ;; NOTE: the custom Chez 'configure' script doesn't allow
+ ;; unrecognized flags, such as those automatically added
+ ;; by `gnu-build-system`.
+ (replace 'configure
(lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((doc (string-append (assoc-ref outputs "doc")
- "/share/doc/" ,name "-" ,version)))
- (invoke "make" "docs")
- (with-directory-excursion "csug"
- (substitute* "Makefile"
- ;; The ‘installdir=’ can't be overruled on the command line.
- (("/tmp/csug9") doc)
- ;; $m is the ‘machine type’, e.g. ‘ta6le’ on x86_64, but is
- ;; set incorrectly for some reason, e.g. to ‘a6le’ on x86_64.
- ;; Avoid the whole mess by running the (machine-independent)
- ;; ‘installsh’ script at its original location.
- (("\\$m/installsh") "makefiles/installsh"))
- (invoke "make" "install")
- (install-file "csug.pdf" doc))
- (with-directory-excursion "release_notes"
- (install-file "release_notes.pdf" doc))
+ (let* ((zlib-static (assoc-ref inputs "zlib:static"))
+ (lz4-static (assoc-ref inputs "lz4:static"))
+ (out (assoc-ref outputs "out"))
+ (flags (list
+ (string-append "--installprefix=" out)
+ (string-append "ZLIB=" zlib-static "/lib/libz.a")
+ (string-append "LZ4=" lz4-static "/lib/liblz4.a")
+ "--nogzip-man-pages" ;; guix will do it
+ "--threads"))
+ (flags (if (assoc-ref inputs "ncurses")
+ flags
+ (cons "--disable-curses"
+ flags)))
+ (flags (if (assoc-ref inputs "libx11")
+ flags
+ (cons "--disable-x11"
+ flags))))
+ ;; Some makefiles (for tests) don't seem to propagate CC
+ ;; properly, so we take it out of their hands:
+ (setenv "CC" "gcc")
+ (apply invoke
+ "./configure"
+ flags)
#t)))
- ;; The binary file name is called "scheme" as the one from MIT/GNU
+ ;; The binary file name is called "scheme" as is the one from MIT/GNU
;; Scheme. We add a symlink to use in case both are installed.
(add-after 'install 'install-symlink
(lambda* (#:key outputs #:allow-other-keys)
@@ -207,16 +198,73 @@
"/" name ".boot")))
(find-files lib "scheme.boot"))
#t)))
- (add-before 'reset-gzip-timestamps 'make-manpages-writable
- (lambda* (#:key outputs #:allow-other-keys)
- (map (lambda (file)
- (make-file-writable file))
- (find-files (string-append (assoc-ref outputs "out")
- "/share/man")
- ".*\\.gz$"))
- #t)))))
+ ;; Building explicitly lets us avoid using substitute*
+ ;; to re-write makefiles.
+ (add-after 'install-symlink 'build+install-stex
+ (lambda* (#:key native-inputs inputs outputs #:allow-other-keys)
+ (let* ((stex+version
+ (strip-store-file-name
+ (assoc-ref (or native-inputs inputs) "stex")))
+ ;; Eventually we want to install stex as a real
+ ;; package so it's reusable. For now:
+ (stex-output "/tmp")
+ (doc-dir (string-append stex-output
+ "/share/doc/"
+ stex+version)))
+ (with-directory-excursion "stex"
+ (invoke "make"
+ "install"
+ (string-append "LIB="
+ stex-output
+ "/lib/"
+ stex+version)
+ (string-append "Scheme="
+ (assoc-ref outputs "out")
+ "/bin/scheme"))
+ (for-each (lambda (pth)
+ (install-file pth doc-dir))
+ '("ReadMe" ; includes the license
+ "doc/stex.html"
+ "doc/stex.css"
+ "doc/stex.pdf"))
+ #t))))
+ ;; Building the documentation requires stex and a running scheme.
+ ;; FIXME: this is probably wrong for cross-compilation
+ (add-after 'build+install-stex 'build+install-doc
+ (lambda* (#:key native-inputs inputs outputs #:allow-other-keys)
+ (let* ((chez+version (strip-store-file-name
+ (assoc-ref outputs "out")))
+ (stex+version
+ (strip-store-file-name
+ (assoc-ref (or native-inputs inputs) "stex")))
+ (scheme (string-append (assoc-ref outputs "out")
+ "/bin/scheme"))
+ ;; see note on stex-output in phase build-stex, above:
+ (stexlib (string-append "/tmp"
+ "/lib/"
+ stex+version))
+ (doc-dir (string-append (assoc-ref outputs "doc")
+ "/share/doc/"
+ chez+version)))
+ (define* (stex-make #:optional (suffix ""))
+ (invoke "make"
+ "install"
+ (string-append "Scheme=" scheme)
+ (string-append "STEXLIB=" stexlib)
+ (string-append "installdir=" doc-dir suffix)))
+ (with-directory-excursion "csug"
+ (stex-make "/csug"))
+ (with-directory-excursion "release_notes"
+ (stex-make "/release_notes"))
+ (with-directory-excursion doc-dir
+ (symlink "release_notes/release_notes.pdf"
+ "release_notes.pdf")
+ (symlink "csug/csug9_5.pdf"
+ "csug.pdf"))
+ #t))))))
;; According to the documentation MIPS is not supported.
;; Cross-compiling for the Raspberry Pi is supported, but not native ARM.
+ ;; TODO is this correct? Chez has an arm32le machine type.
(supported-systems (fold delete %supported-systems
'("mips64el-linux" "armhf-linux")))
(home-page "https://cisco.github.io/ChezScheme/")
@@ -228,6 +276,7 @@ generates native code for each target processor, with support for x86, x86_64,
and 32-bit PowerPC architectures.")
(license asl2.0)))
+
(define-public chez-srfi
(package
(name "chez-srfi")
diff --git a/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch b/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch
new file mode 100644
index 0000000000..07d65225ed
--- /dev/null
+++ b/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch
@@ -0,0 +1,780 @@
+From 2447e047b750c3371778beb487f881641a582e66 Mon Sep 17 00:00:00 2001
+From: Philip McGrath <philip@philipmcgrath.com>
+Date: Thu, 11 Mar 2021 18:17:47 -0500
+Subject: [PATCH] avoid hard-coded paths for utilities in build scripts
+
+Backported from
+https://github.com/cisco/ChezScheme/commit/8f4633ce24ac6425b2ab13cc78026b1c9bb5361e
+
+Specific changes:
+ - `cc` -> `$(CC)`
+ - `/bin/rm` -> `rm`
+ - `/bin/ln` -> `ln`
+ - `/bin/cp` -> `cp`
+ - `/bin/echo` -> `echo`
+ - in `makefiles/installsh`, add a case to find `true`
+ at an unusual path or as a shell builtin
+
+Co-authored-by: Andy Keep <akeep@robotman.org>
+---
+ LOG | 12 ++++++++++++
+ csug/gifs/Makefile | 8 ++++----
+ csug/math/Makefile | 4 ++--
+ examples/Makefile | 2 +-
+ makefiles/Makefile-csug.in | 6 +++---
+ makefiles/Makefile-release_notes.in | 2 +-
+ makefiles/Mf-install.in | 4 ++--
+ makefiles/installsh | 3 ++-
+ mats/6.ms | 2 +-
+ mats/Mf-a6fb | 4 ++--
+ mats/Mf-a6le | 4 ++--
+ mats/Mf-a6nb | 4 ++--
+ mats/Mf-a6ob | 4 ++--
+ mats/Mf-a6osx | 4 ++--
+ mats/Mf-arm32le | 4 ++--
+ mats/Mf-i3fb | 4 ++--
+ mats/Mf-i3le | 4 ++--
+ mats/Mf-i3nb | 4 ++--
+ mats/Mf-i3ob | 4 ++--
+ mats/Mf-i3osx | 4 ++--
+ mats/Mf-i3qnx | 4 ++--
+ mats/Mf-ppc32le | 4 ++--
+ mats/Mf-ta6fb | 4 ++--
+ mats/Mf-ta6le | 4 ++--
+ mats/Mf-ta6nb | 4 ++--
+ mats/Mf-ta6ob | 4 ++--
+ mats/Mf-ta6osx | 4 ++--
+ mats/Mf-ti3fb | 4 ++--
+ mats/Mf-ti3le | 4 ++--
+ mats/Mf-ti3nb | 4 ++--
+ mats/Mf-ti3ob | 4 ++--
+ mats/Mf-ti3osx | 4 ++--
+ mats/Mf-tppc32le | 4 ++--
+ mats/unix.ms | 4 ++--
+ newrelease | 22 +++++++++++-----------
+ pkg/Makefile | 2 +-
+ release_notes/gifs/Makefile | 6 +++---
+ release_notes/math/Makefile | 4 ++--
+ s/Mf-base | 2 +-
+ workarea | 10 +++++-----
+ 40 files changed, 101 insertions(+), 88 deletions(-)
+
+diff --git a/LOG b/LOG
+index e1631df..399104d 100644
+--- a/LOG
++++ b/LOG
+@@ -2119,3 +2119,15 @@
+ bintar/Makefile rpm/Makefile pkg/Makefile wininstall/Makefile
+ wininstall/a6nt.wxs wininstall/i3nt.wxs wininstall/ta6nt.wxs
+
This message was truncated. Download the full message here.
L
L
Leo Prikler wrote on 16 Mar 2021 08:37
Re: [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.
6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at
Hi,

Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
Toggle quote (4 lines)
> - (sha256 (base32
> "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
> + (sha256
> "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
You're inadvertently stripping away base32.

Toggle quote (4 lines)
> - (sha256 (base32
> "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
> + (sha256
> "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
Same here.

Toggle quote (6 lines)
> - (commit (string-append "v" version))))
> + ;; This commit includes a fix for which we would
> + ;; otherwise want to use a snippet.
> + ;; When there's a new tagged release,
> + ;; go back to using (string-append "v" version)
> + (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
Could we then not cherry-pick this commit as a patch? Or is there more
needed?

Toggle quote (10 lines)
> + ;; pre-built bootfiles for unsupported
> systems:
> + "boot/a6nt"
> + "boot/a6osx"
> + "boot/i3nt"
> + "boot/i3osx"
> + "boot/ta6nt"
> + "boot/ta6osx"
> + "boot/ti3nt"
> + "boot/ti3osx")))))))
What about pre-built bootfiles for supported systems? Do we still need
those? If we so, I don't think it is right to delete anything in boot;
if not we should delete it altogether.

Toggle quote (6 lines)
> + ;; put these where configure expects them to be
> + (add-after 'unpack 'unpack-nanopass+stex
> + (lambda* (#:key native-inputs inputs #:allow-other-keys)
> + (let ((patch-source-shebangs
> (assoc-ref %standard-phases 'patch-source-
> shebangs)))
I don't think you need patch-source-shebangs directly after unpack.
Those shebangs would be patched in their phase anyway – the only reason
we needed it before was because we delayed unpacking until configure.

Toggle quote (1 lines)
> + (setenv "CC" "gcc")
This should be determined via cc-for-target.

Toggle quote (3 lines)
> + (apply invoke
> + "./configure"
> + flags)
This can very likely be one line. Also, it should probably be done via
configure-flags.

Toggle quote (1 lines)
> [outputs]: Add "stex"
I don't think an stex output is justified in and of itself, or is it
needed for chez to function? (Even if it was, it would then need to be
part of the "out" output.) I personally doubt this; if you need stex
itself for your purposes, you can try packaging it later.

Toggle quote (8 lines)
> + (flags (if (assoc-ref inputs "ncurses")
> + flags
> + (cons "--disable-curses"
> + flags)))
> + (flags (if (assoc-ref inputs "libx11")
> + flags
> + (cons "--disable-x11"
> + flags))))
These will probably be detected by the build system itself, there's no
need for you to add them. If not, then it's up to the packager of
other variants to specify them, not you.

Toggle quote (8 lines)
> + (flags (list
> + (string-append "--installprefix=" out)
> + (string-append "ZLIB=" zlib-static
> "/lib/libz.a")
> + (string-append "LZ4=" lz4-static
> "/lib/liblz4.a")
> + "--nogzip-man-pages" ;; guix will do it
> + "--threads"))
This should be done via #:configure-flags.

Now that I think of it…

Toggle quote (1 lines)
> + (replace 'configure
I don't think this is needed at all. At most, you should filter the
incompatible flags from configure-flags in some way, but you might also
want to patch configure, so that it swallows them.

Toggle quote (2 lines)
> Refactor 'install-doc' phase into 'build+install-stex' and
> 'build+install-doc'
'build+install' implies, that it should actually be two phases, build
and install. I already talked about install-stex, so you should only
refactor install-doc insofar as it is needed to accommodate changes in
the build system.

Regards,
Leo
P
P
Philip McGrath wrote on 16 Mar 2021 21:19
5a4d612f-445a-e3f0-a3ff-7abd4b021f16@philipmcgrath.com
Hi,

On 3/16/21 3:37 AM, Leo Prikler wrote:
Toggle quote (7 lines)
> Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
>> - (sha256 (base32
>> "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
>> + (sha256
>> "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
> You're inadvertently stripping away base32.

I thought I'd read that explicitly calling base32 was redundant and no
longer recommended: is there a reason to keep it?


Toggle quote (9 lines)
>> - (commit (string-append "v" version))))
>> + ;; This commit includes a fix for which we would
>> + ;; otherwise want to use a snippet.
>> + ;; When there's a new tagged release,
>> + ;; go back to using (string-append "v" version)
>> + (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
> Could we then not cherry-pick this commit as a patch? Or is there more
> needed?

We could, but the upstream history is simply v1.2.2 -> my patch -> Kent
Dybvig's merge commit accepting it. I thought doing it this way
clarified that it's not a Guix-specific patch that should stay around
indefinitely. Is there a reason to prefer cherry-picking it as a patch?


Toggle quote (15 lines)
>
>> + ;; pre-built bootfiles for unsupported
>> systems:
>> + "boot/a6nt"
>> + "boot/a6osx"
>> + "boot/i3nt"
>> + "boot/i3osx"
>> + "boot/ta6nt"
>> + "boot/ta6osx"
>> + "boot/ti3nt"
>> + "boot/ti3osx")))))))
> What about pre-built bootfiles for supported systems? Do we still need
> those? If we so, I don't think it is right to delete anything in boot;
> if not we should delete it altogether.

Currently, you need a bootfile for your current system to bootstrap the
Chez compiler; once you have a running Chez, you can build bootfiles for
any system Chez supports (which is more systems than it includes in its
git repository for bootstrapping). The bootfiles you build will be
byte-for-byte identical to pre-built ones, if pre-built ones were
provided: Chez in fact builds them twice and errors if they aren't. So,
I'm not sure why we would want these files, which are over 20 MB and are
only useful for bootstrapping Chez on Windows or Mac OS. But if there is
a reason to want them, we can keep them!

Toggle quote (10 lines)
>> + ;; put these where configure expects them to be
>> + (add-after 'unpack 'unpack-nanopass+stex
>> + (lambda* (#:key native-inputs inputs #:allow-other-keys)
>> + (let ((patch-source-shebangs
>> (assoc-ref %standard-phases 'patch-source-
>> shebangs)))
> I don't think you need patch-source-shebangs directly after unpack.
> Those shebangs would be patched in their phase anyway – the only reason
> we needed it before was because we delayed unpacking until configure.

Right, thanks for catching this!

Toggle quote (3 lines)
>> + (setenv "CC" "gcc")
> This should be determined via cc-for-target.

Will do.

Toggle quote (9 lines)
>> + (apply invoke
>> + "./configure"
>> + flags)
> This can very likely be one line. Also, it should probably be done via
> configure-flags.
>
>> [outputs]: Add "stex"
> I don't think an stex output is justified in and of itself, or is it

Oops, I'd actually removed the "stex" output, but I missed it in the
commit message.

Toggle quote (12 lines)
>> + (flags (if (assoc-ref inputs "ncurses")
>> + flags
>> + (cons "--disable-curses"
>> + flags)))
>> + (flags (if (assoc-ref inputs "libx11")
>> + flags
>> + (cons "--disable-x11"
>> + flags))))
> These will probably be detected by the build system itself, there's no
> need for you to add them. If not, then it's up to the packager of
> other variants to specify them, not you.

IIRC, Chez's build system errors without these flags if the library
isn't found. Also, I intend to be "the packager of the other
variants"—my primary motivation for sending these patches is to reuse as
much as possible for Racket's fork of Chez, rather than all of the messy
copy-pasting we're doing now. But see below …

Toggle quote (17 lines)
>> + (flags (list
>> + (string-append "--installprefix=" out)
>> + (string-append "ZLIB=" zlib-static
>> "/lib/libz.a")
>> + (string-append "LZ4=" lz4-static
>> "/lib/liblz4.a")
>> + "--nogzip-man-pages" ;; guix will do it
>> + "--threads"))
> This should be done via #:configure-flags.
>
> Now that I think of it…
>
>> + (replace 'configure
> I don't think this is needed at all. At most, you should filter the
> incompatible flags from configure-flags in some way, but you might also
> want to patch configure, so that it swallows them.

I'm not enthusiastic about the idea of maintaining such a patch for two
variants of this custom configure script which accept different sets of
flags, but neither of which accepts *any* of the flags that would be
added by the 'configure phase from %standard-phases. That procedure
offers no way to interpose between its adding the flags and its invoking
the configure script, so I don't see a good alternative to replacing it.
In fact, I'd modeled my implementation on the one from %standard-phases,
which similarly has a big `let*` expression adding implicit phases based
on the inputs and outputs.

If you think it's important to support #:configure-flags, I could change
this implementation to accept them, in which case I'd be ok with leaving
out handling of --disable-curses and --disable-x11. But I think anyone
packaging a variant of Chez will need to be aware of its idiosyncratic
configure script.

Toggle quote (7 lines)
>> Refactor 'install-doc' phase into 'build+install-stex' and
>> 'build+install-doc'
> 'build+install' implies, that it should actually be two phases, build
> and install. I already talked about install-stex, so you should only
> refactor install-doc insofar as it is needed to accommodate changes in
> the build system.

It could be two phases, but the current install-doc phase does, in fact,
also build the docs, in addition to installing them. (It actually
neglects to install the HTML release notes but installs two copies of
the PDF user's guide.) I'm ok with calling it install-doc if you prefer.
I guess I could even split it into two phases, but that seems like it
would just make things more complicated for no obvious benefit.

As I mentioned, build+install-stex actually just "installs" stex to a
temporary directory right now. I think I could probably skip it and rely
on Chez's on-the-fly compilation, but I didn't see a problem with doing
it this way.

-Philip
L
L
Leo Prikler wrote on 16 Mar 2021 22:09
5c833412d1ef4c9130c7f769a7d2c6d4270d7d36.camel@student.tugraz.at
Hi,

Am Dienstag, den 16.03.2021, 16:19 -0400 schrieb Philip McGrath:
Toggle quote (13 lines)
> Hi,
>
> On 3/16/21 3:37 AM, Leo Prikler wrote:
> > Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
> > > - (sha256 (base32
> > > "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
> > > + (sha256
> > > "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
> > You're inadvertently stripping away base32.
>
> I thought I'd read that explicitly calling base32 was redundant and
> no
> longer recommended: is there a reason to keep it?
Without a reference to where you've read that, it'll be hard to verify
or falsify that claim. Both master and core-updates regularly see
sha256/base32 is fancy syntax around hash-digest and hash-algo as far
as I understand, so I doubt you recall this correctly.

Toggle quote (18 lines)
> > > - (commit (string-append "v" version))))
> > > + ;; This commit includes a fix for which we would
> > > + ;; otherwise want to use a snippet.
> > > + ;; When there's a new tagged release,
> > > + ;; go back to using (string-append "v" version)
> > > + (commit
> > > "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
> > Could we then not cherry-pick this commit as a patch? Or is there
> > more
> > needed?
>
> We could, but the upstream history is simply v1.2.2 -> my patch ->
> Kent
> Dybvig's merge commit accepting it. I thought doing it this way
> clarified that it's not a Guix-specific patch that should stay
> around
> indefinitely. Is there a reason to prefer cherry-picking it as a
> patch?
You'll probably hear differing opinions about that, and that's fine,
but my personal reason to prefer cherry-picking would be, that it makes
it very obvious, what changed from the base – that being the patch
modulo offset changes – and doesn't invite people to go out saying
"aha, but I found this commit and I like that more, let's take it". In
other words, this is very subjective, but I believe we should stick as
close to releases as is reasonable.

Toggle quote (31 lines)
> > > + ;; pre-built bootfiles for unsupported
> > > systems:
> > > + "boot/a6nt"
> > > + "boot/a6osx"
> > > + "boot/i3nt"
> > > + "boot/i3osx"
> > > + "boot/ta6nt"
> > > + "boot/ta6osx"
> > > + "boot/ti3nt"
> > > + "boot/ti3osx")))))))
> > What about pre-built bootfiles for supported systems? Do we still
> > need
> > those? If we so, I don't think it is right to delete anything in
> > boot;
> > if not we should delete it altogether.
>
> Currently, you need a bootfile for your current system to bootstrap
> the
> Chez compiler; once you have a running Chez, you can build bootfiles
> for
> any system Chez supports (which is more systems than it includes in
> its
> git repository for bootstrapping). The bootfiles you build will be
> byte-for-byte identical to pre-built ones, if pre-built ones were
> provided: Chez in fact builds them twice and errors if they aren't.
> So,
> I'm not sure why we would want these files, which are over 20 MB and
> are
> only useful for bootstrapping Chez on Windows or Mac OS. But if there
> is
> a reason to want them, we can keep them!
I don't think we can necessarily trust the boot files in this
configuration. "They are bit-for-bit identical" can also mean, that
the login() hack was successfully applied for all you know. But
trusting trust aside, I don't think this is the right way of
"miraculously slashing" half of chez' bootstrap. If you do want to
follow the direction of making the bootstrap explicit, how about a
chez-boot minipackage, that only keeps the relevant boot files for the
target system? (This would of course need to be done in a separate
patch, which you can attach to this series, however.)

Toggle quote (13 lines)
> > > + (apply invoke
> > > + "./configure"
> > > + flags)
> > This can very likely be one line. Also, it should probably be done
> > via
> > configure-flags.
> >
> > > [outputs]: Add "stex"
> > I don't think an stex output is justified in and of itself, or is
> > it
>
> Oops, I'd actually removed the "stex" output, but I missed it in the
> commit message.
I do think I saw it in the actual commit as well, but I might be
mistaken about that.

Toggle quote (20 lines)
> > > + (flags (if (assoc-ref inputs "ncurses")
> > > + flags
> > > + (cons "--disable-curses"
> > > + flags)))
> > > + (flags (if (assoc-ref inputs "libx11")
> > > + flags
> > > + (cons "--disable-x11"
> > > + flags))))
> > These will probably be detected by the build system itself, there's
> > no
> > need for you to add them. If not, then it's up to the packager of
> > other variants to specify them, not you.
>
> IIRC, Chez's build system errors without these flags if the library
> isn't found. Also, I intend to be "the packager of the other
> variants"—my primary motivation for sending these patches is to reuse
> as
> much as possible for Racket's fork of Chez, rather than all of the
> messy
> copy-pasting we're doing now. But see below …
Fair enough, but either way you should just cons them onto #:configure-
flags where applicable.

Toggle quote (46 lines)
> > > + (flags (list
> > > + (string-append "--installprefix="
> > > out)
> > > + (string-append "ZLIB=" zlib-static
> > > "/lib/libz.a")
> > > + (string-append "LZ4=" lz4-static
> > > "/lib/liblz4.a")
> > > + "--nogzip-man-pages" ;; guix will do
> > > it
> > > + "--threads"))
> > This should be done via #:configure-flags.
> >
> > Now that I think of it…
> >
> > > + (replace 'configure
> > I don't think this is needed at all. At most, you should filter
> > the
> > incompatible flags from configure-flags in some way, but you might
> > also
> > want to patch configure, so that it swallows them.
>
> I'm not enthusiastic about the idea of maintaining such a patch for
> two
> variants of this custom configure script which accept different sets
> of
> flags, but neither of which accepts *any* of the flags that would be
> added by the 'configure phase from %standard-phases. That procedure
> offers no way to interpose between its adding the flags and its
> invoking
> the configure script, so I don't see a good alternative to replacing
> it.
> In fact, I'd modeled my implementation on the one from %standard-
> phases,
> which similarly has a big `let*` expression adding implicit phases
> based
> on the inputs and outputs.
>
> If you think it's important to support #:configure-flags, I could
> change
> this implementation to accept them, in which case I'd be ok with
> leaving
> out handling of --disable-curses and --disable-x11. But I think
> anyone
> packaging a variant of Chez will need to be aware of its
> idiosyncratic
> configure script.
Perhaps I was a little too harsh. If you need to replace 'configure to
not let gnu-build-system's own flags pass into this idiosyncratic
script, you are of course allowed to do that. I just think storing
configure flags inside the argument that's named like that is a better
choice, than an ad-hoc construction. Whatever you see inside that
standard-phase is done precisely because storing it as an argument
would not be an option.

Toggle quote (20 lines)
> > > Refactor 'install-doc' phase into 'build+install-stex' and
> > > 'build+install-doc'
> > 'build+install' implies, that it should actually be two phases,
> > build
> > and install. I already talked about install-stex, so you should
> > only
> > refactor install-doc insofar as it is needed to accommodate changes
> > in
> > the build system.
>
> It could be two phases, but the current install-doc phase does, in
> fact,
> also build the docs, in addition to installing them. (It actually
> neglects to install the HTML release notes but installs two copies
> of
> the PDF user's guide.) I'm ok with calling it install-doc if you
> prefer.
> I guess I could even split it into two phases, but that seems like
> it
> would just make things more complicated for no obvious benefit.
That is irrelevant, `make install' is not prohibited from building
stuff.

Toggle quote (7 lines)
> As I mentioned, build+install-stex actually just "installs" stex to
> a
> temporary directory right now. I think I could probably skip it and
> rely
> on Chez's on-the-fly compilation, but I didn't see a problem with
> doing
> it this way.
Sounds like it might work.

Regards,
Leo
P
P
Philip McGrath wrote on 19 Mar 2021 19:24
[PATCH v3 1/3] gnu: chez-scheme: Update nanopass to 1.9.2.
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210319182451.840-1-philip@philipmcgrath.com
* gnu/packages/chez.scm (nanopass): Update nanopass to 1.9.2.
---
gnu/packages/chez.scm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

Toggle diff (30 lines)
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index eac556c4d0..5dd1185c43 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2019 Brett Gilio <brettg@gnu.org>
;;; Copyright © 2020 Brendan Tildesley <mail@brendan.scot>
+;;; Copyright © 2021 Philip McGrath <philip@philipmcgrath.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -43,13 +44,13 @@
#:use-module (srfi srfi-1))
(define nanopass
- (let ((version "1.9.1"))
+ (let ((version "1.9.2"))
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/nanopass/nanopass-framework-scheme")
(commit (string-append "v" version))))
- (sha256 (base32 "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
+ (sha256 "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
(file-name (git-file-name "nanopass" version)))))
(define stex
--
2.21.1 (Apple Git-122.3)
P
P
Philip McGrath wrote on 19 Mar 2021 19:24
[PATCH v3 2/3] gnu: chez-scheme: Update stex.
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210319182451.840-2-philip@philipmcgrath.com
Get a patch from upstream that will help us simplify the build process
for the Chez Scheme documentation.

* gnu/packages/chez.scm (chez-stex): Update to commit 5405149.
---
gnu/packages/chez.scm | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index 5dd1185c43..dd0db04d88 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -59,8 +59,12 @@
(method git-fetch)
(uri (git-reference
(url "https://github.com/dybvig/stex")
- (commit (string-append "v" version))))
- (sha256 (base32 "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
+ ;; This commit includes a fix for which we would
+ ;; otherwise want to use a snippet.
+ ;; When there's a new tagged release,
+ ;; go back to using (string-append "v" version)
+ (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
+ (sha256 "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
(file-name (git-file-name "stex" version)))))
(define-public chez-scheme
--
2.21.1 (Apple Git-122.3)
P
P
Philip McGrath wrote on 19 Mar 2021 19:24
[PATCH v3 3/3] gnu: chez-scheme: simplify packaging
(address . 47153@debbugs.gnu.org)(name . Philip McGrath)(address . philip@philipmcgrath.com)
20210319182451.840-3-philip@philipmcgrath.com
Take advantage of patches that have been accepted upstream.
These changes lay a foundation for reusing more of Chez's
build process for Racket.

* gnu/packages/patches/chez-scheme-build-util-paths-backport.patch:
New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/chez.scm (chez-scheme)[source](patches): Use it.
[source](snippet): Remove bundled libraries here, not in configure phase.
[inputs]: Organize. Move "nanopass", "stex", and "xorg-rgb" to ...
[native-inputs]: ... this field.
[arguments]: Add (ice-9 ftw) to #:modules. Remove unneeded
'patch-processor-detection' phase. Add 'unpack-nanopass+stex' phase
(refactored from 'configure'). Simplify 'configure' phase by removing
patches that have been upstreamed. Add "--nogzip-man-pages" flag so we can
remove 'make-manpages-writable' phase. Stop ignoring #:configure-flags,
move "--threads" there, and remove unneeded workaround. Add 'prepare-stex'
phase (refactored from 'install-doc'). Use it to streamline 'install-doc'
phase, installing all of the right files into the right places.
---
gnu/local.mk | 1 +
gnu/packages/chez.scm | 247 +++---
...hez-scheme-build-util-paths-backport.patch | 780 ++++++++++++++++++
3 files changed, 924 insertions(+), 104 deletions(-)
create mode 100644 gnu/packages/patches/chez-scheme-build-util-paths-backport.patch

Toggle diff (389 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index 8325c071bd..bf81c9157e 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -886,6 +886,7 @@ dist_patch_DATA = \
%D%/packages/patches/cdrtools-3.01-mkisofs-isoinfo.patch \
%D%/packages/patches/ceph-disable-cpu-optimizations.patch \
%D%/packages/patches/cgal-security-pr-5371.patch \
+ %D%/packages/patches/chez-scheme-build-util-paths-backport.patch \
%D%/packages/patches/chmlib-inttypes.patch \
%D%/packages/patches/cl-asdf-config-directories.patch \
%D%/packages/patches/clamav-config-llvm-libs.patch \
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm
index dd0db04d88..b77fc8ba5f 100644
--- a/gnu/packages/chez.scm
+++ b/gnu/packages/chez.scm
@@ -30,6 +30,7 @@
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix utils)
+ #:use-module (guix gexp)
#:use-module (guix build-system gnu)
#:use-module (gnu packages compression)
#:use-module (gnu packages ncurses)
@@ -79,21 +80,41 @@
(commit (string-append "v" version))))
(sha256
(base32 "0prgn2z9l888j93ydxaf04ph424g0fi3a8w7f8m0b2r7fr1v7388"))
- (file-name (git-file-name name version))))
+ (file-name (git-file-name name version))
+ (patches
+ (search-patches
+ ;; backported from upstream: remove on next release
+ "chez-scheme-build-util-paths-backport.patch"))
+ (snippet
+ ;; remove bundled libraries
+ (with-imported-modules '((guix build utils))
+ #~(begin
+ (use-modules (guix build utils))
+ (for-each (lambda (dir)
+ (when (directory-exists? dir)
+ (delete-file-recursively dir)))
+ '("stex"
+ "nanopass"
+ "lz4"
+ "zlib")))))))
(build-system gnu-build-system)
(inputs
- `(("ncurses" ,ncurses)
- ("libuuid" ,util-linux "lib")
- ("libx11" ,libx11)
- ("lz4" ,lz4)
- ("lz4:static" ,lz4 "static")
- ("xorg-rgb" ,xorg-rgb)
- ("nanopass" ,nanopass)
+ `(("libuuid" ,util-linux "lib")
("zlib" ,zlib)
("zlib:static" ,zlib "static")
- ("stex" ,stex)))
+ ("lz4" ,lz4)
+ ("lz4:static" ,lz4 "static")
+ ;; for expeditor:
+ ("ncurses" ,ncurses)
+ ;; for X11 clipboard support in expeditor:
+ ;; https://github.com/cisco/ChezScheme/issues/9#issuecomment-222057232
+ ("libx11" ,libx11)))
(native-inputs
- `(("texlive" ,(texlive-union (list texlive-latex-oberdiek
+ `(("nanopass" ,nanopass) ; source only
+ ;; for docs
+ ("stex" ,stex)
+ ("xorg-rgb" ,xorg-rgb)
+ ("texlive" ,(texlive-union (list texlive-latex-oberdiek
texlive-generic-epsf)))
("ghostscript" ,ghostscript)
("netpbm" ,netpbm)))
@@ -103,96 +124,54 @@
(files (list (string-append "lib/csv" version "-site"))))))
(outputs '("out" "doc"))
(arguments
- `(#:modules ((guix build gnu-build-system)
- (guix build utils)
- (ice-9 match))
+ `(#:modules
+ ((guix build gnu-build-system)
+ (guix build utils)
+ (ice-9 ftw)
+ (ice-9 match))
#:test-target "test"
#:configure-flags
- (list ,(match (or (%current-target-system) (%current-system))
- ("x86_64-linux" '(list "--machine=ta6le"))
- ("i686-linux" '(list "--machine=ti3le"))
- ;; Let autodetection have its attempt on other architectures.
- (_
- '())))
+ '("--threads") ;; TODO when we fix armhf, it doesn't support --threads
#:phases
(modify-phases %standard-phases
- (add-after 'unpack 'patch-processor-detection
- (lambda _ (substitute* "configure"
- (("uname -a") "uname -m"))
- #t))
- ;; Adapt the custom 'configure' script.
+ ;; put these where configure expects them to be
+ (add-after 'unpack 'unpack-nanopass+stex
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (for-each (lambda (dep)
+ (define src
+ (assoc-ref (or native-inputs inputs) dep))
+ (copy-recursively src dep
+ #:keep-mtime? #t))
+ '("nanopass" "stex"))
+ #t))
+ ;; NOTE: the custom Chez 'configure' script doesn't allow
+ ;; unrecognized flags, such as those automatically added
+ ;; by `gnu-build-system`.
(replace 'configure
- (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out"))
- (nanopass (assoc-ref inputs "nanopass"))
- (stex (assoc-ref inputs "stex"))
- (lz4-static (assoc-ref inputs "lz4:static"))
- (zlib-static (assoc-ref inputs "zlib:static"))
- (unpack (assoc-ref %standard-phases 'unpack))
- (patch-source-shebangs
- (assoc-ref %standard-phases 'patch-source-shebangs)))
- (map (match-lambda
- ((src orig-name new-name)
- (with-directory-excursion "."
- (apply unpack (list #:source src))
- (apply patch-source-shebangs (list #:source src)))
- (delete-file-recursively new-name)
- (invoke "mv" orig-name new-name)))
- `((,nanopass "source" "nanopass")
- (,stex "source" "stex")))
- ;; The configure step wants to CURL all submodules as it
- ;; detects a checkout without submodules. Disable curling,
- ;; and manually patch the needed modules for compilation.
- (substitute* "configure"
- (("! -f '") "-d '")) ; working around CURL.
- (substitute* (find-files "mats" "Mf-.*")
- (("^[[:space:]]+(cc ) *") "\tgcc "))
- (substitute*
- (find-files "." (string-append
- "("
- "Mf-[a-zA-Z0-9.]+"
- "|Makefile[a-zA-Z0-9.]*"
- "|checkin"
- "|stex\\.stex"
- "|newrelease"
- "|workarea"
- "|unix\\.ms"
- "|^6\\.ms"
- ;;"|[a-zA-Z0-9.]+\\.ms" ; guile can't read
- ")"))
- (("/bin/rm") (which "rm"))
- (("/bin/ln") (which "ln"))
- (("/bin/cp") (which "cp"))
- (("/bin/echo") (which "echo")))
- (substitute* "makefiles/installsh"
- (("/bin/true") (which "true")))
- (substitute* "stex/Makefile"
- (("PREFIX=/usr") (string-append "PREFIX=" out)))
- (invoke "./configure" "--threads"
- (string-append "ZLIB=" zlib-static "/lib/libz.a")
- (string-append "LZ4=" lz4-static "/lib/liblz4.a")
- (string-append "--installprefix=" out)))))
- ;; Installation of the documentation requires a running "chez".
- (add-after 'install 'install-doc
- (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((doc (string-append (assoc-ref outputs "doc")
- "/share/doc/" ,name "-" ,version)))
- (invoke "make" "docs")
- (with-directory-excursion "csug"
- (substitute* "Makefile"
- ;; The ‘installdir=’ can't be overruled on the command line.
- (("/tmp/csug9") doc)
- ;; $m is the ‘machine type’, e.g. ‘ta6le’ on x86_64, but is
- ;; set incorrectly for some reason, e.g. to ‘a6le’ on x86_64.
- ;; Avoid the whole mess by running the (machine-independent)
- ;; ‘installsh’ script at its original location.
- (("\\$m/installsh") "makefiles/installsh"))
- (invoke "make" "install")
- (install-file "csug.pdf" doc))
- (with-directory-excursion "release_notes"
- (install-file "release_notes.pdf" doc))
+ (lambda* (#:key inputs outputs
+ (configure-flags '())
+ #:allow-other-keys)
+ (let* ((zlib-static (assoc-ref inputs "zlib:static"))
+ (lz4-static (assoc-ref inputs "lz4:static"))
+ (out (assoc-ref outputs "out"))
+ ;; add flags which are always required:
+ (flags (cons*
+ (string-append "--installprefix=" out)
+ (string-append "ZLIB=" zlib-static "/lib/libz.a")
+ (string-append "LZ4=" lz4-static "/lib/liblz4.a")
+ ;; Guix will do compress man pages,
+ ;; and letting Chez try causes an error
+ "--nogzip-man-pages"
+ configure-flags)))
+ (format #t "configure flags: ~s~%" flags)
+ ;; Some makefiles (for tests) don't seem to propagate CC
+ ;; properly, so we take it out of their hands:
+ (setenv "CC" ,(cc-for-target))
+ (apply invoke
+ "./configure"
+ flags)
#t)))
- ;; The binary file name is called "scheme" as the one from MIT/GNU
+ ;; The binary file name is called "scheme" as is the one from MIT/GNU
;; Scheme. We add a symlink to use in case both are installed.
(add-after 'install 'install-symlink
(lambda* (#:key outputs #:allow-other-keys)
@@ -207,16 +186,75 @@
"/" name ".boot")))
(find-files lib "scheme.boot"))
#t)))
- (add-before 'reset-gzip-timestamps 'make-manpages-writable
- (lambda* (#:key outputs #:allow-other-keys)
- (map (lambda (file)
- (make-file-writable file))
- (find-files (string-append (assoc-ref outputs "out")
- "/share/man")
- ".*\\.gz$"))
- #t)))))
- ;; According to the documentation MIPS is not supported.
- ;; Cross-compiling for the Raspberry Pi is supported, but not native ARM.
+ ;; Building explicitly lets us avoid using substitute*
+ ;; to re-write makefiles.
+ (add-after 'install-symlink 'prepare-stex
+ (lambda* (#:key native-inputs inputs outputs #:allow-other-keys)
+ (let* ((stex+version
+ (strip-store-file-name
+ (assoc-ref (or native-inputs inputs) "stex")))
+ ;; Eventually we want to install stex as a real
+ ;; package so it's reusable. For now:
+ (stex-output "/tmp")
+ (doc-dir (string-append stex-output
+ "/share/doc/"
+ stex+version)))
+ (with-directory-excursion "stex"
+ (invoke "make"
+ "install"
+ (string-append "LIB="
+ stex-output
+ "/lib/"
+ stex+version)
+ (string-append "Scheme="
+ (assoc-ref outputs "out")
+ "/bin/scheme"))
+ (for-each (lambda (pth)
+ (install-file pth doc-dir))
+ '("ReadMe" ; includes the license
+ "doc/stex.html"
+ "doc/stex.css"
+ "doc/stex.pdf"))
+ #t))))
+ ;; Building the documentation requires stex and a running scheme.
+ ;; FIXME: this is probably wrong for cross-compilation
+ (add-after 'prepare-stex 'install-doc
+ (lambda* (#:key native-inputs inputs outputs #:allow-other-keys)
+ (let* ((chez+version (strip-store-file-name
+ (assoc-ref outputs "out")))
+ (stex+version
+ (strip-store-file-name
+ (assoc-ref (or native-inputs inputs) "stex")))
+ (scheme (string-append (assoc-ref outputs "out")
+ "/bin/scheme"))
+ ;; see note on stex-output in phase build-stex, above:
+ (stexlib (string-append "/tmp"
+ "/lib/"
+ stex+version))
+ (doc-dir (string-append (assoc-ref outputs "doc")
+ "/share/doc/"
+ chez+version)))
+ (define* (stex-make #:optional (suffix ""))
+ (invoke "make"
+ "install"
+ (string-append "Scheme=" scheme)
+ (string-append "STEXLIB=" stexlib)
+ (string-append "installdir=" doc-dir suffix)))
+ (with-directory-excursion "csug"
+ (stex-make "/csug"))
+ (with-directory-excursion "release_notes"
+ (stex-make "/release_notes"))
+ (with-directory-excursion doc-dir
+ (symlink "release_notes/release_notes.pdf"
+ "release_notes.pdf")
+ (symlink "csug/csug9_5.pdf"
+ "csug.pdf"))
+ #t))))))
+ ;; Chez Scheme does not have a MIPS backend.
+ ;; FIXME: Debian backports patches to get armhf working.
+ ;; We should too. It is the Chez machine type arm32le
+ ;; (no threaded version upstream yet, though there is in
+ ;; Racket's fork), more specifically (per the release notes) ARMv6.
(supported-systems (fold delete %supported-systems
'("mips64el-linux" "armhf-linux")))
(home-page "https://cisco.github.io/ChezScheme/")
@@ -228,6 +266,7 @@ generates native code for each target processor, with support for x86, x86_64,
and 32-bit PowerPC architectures.")
(license asl2.0)))
+
(define-public chez-srfi
(package
(name "chez-srfi")
diff --git a/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch b/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch
new file mode 100644
index 0000000000..07d65225ed
--- /dev/null
+++ b/gnu/packages/patches/chez-scheme-build-util-paths-backport.patch
@@ -0,0 +1,780 @@
+From 2447e047b750c3371778beb487f881641a582e66 Mon Sep 17 00:00:00 2001
+From: Philip McGrath <philip@philipmcgrath.com>
+Date: Thu, 11 Mar 2021 18:17:47 -0500
+Subject: [PATCH] avoid hard-coded paths for utilities in build scripts
+
+Backported from
+https://github.com/cisco/ChezScheme/commit/8f4633ce24ac6425b2ab13cc78026b1c9bb5361e
+
+Specific changes:
+ - `cc` -> `$(CC)`
+ - `/bin/rm` -> `rm`
+ - `/bin/ln` -> `ln`
+ - `/bin/cp` -> `cp`
+ - `/bin/echo` -> `echo`
+ - in `makefiles/installsh`, add a case to find `true`
+ at an unusual path or as a shell builtin
+
+Co-authored-by: Andy Keep <akeep@robotman.org>
+---
+ LOG | 12 ++++++++++++
+ csug/gifs/Makefile | 8 ++++----
+ csug/math/Makefile | 4 ++--
+ examples/Makefile | 2 +-
+ makefiles/Makefile-csug.in | 6 +++---
+ makefiles/Makefile-release_notes.in | 2 +-
+ makefiles/Mf-install.in | 4 ++--
+ makefiles/installsh | 3 ++-
+ mats/6.ms | 2 +-
+ mats/Mf-a6fb | 4 ++--
+ mats/Mf-a6le | 4 ++--
+ mats/Mf-a6nb | 4 ++--
+ mats/Mf-a6ob | 4 ++--
+ mats/Mf-a6osx | 4 ++--
+ mats/Mf-arm32le | 4 ++--
+ mats/Mf-i3fb | 4 ++--
+ mats/Mf-i3le | 4 ++--
+ mats/Mf-i3nb | 4 ++--
+ mats/Mf-i3ob | 4 ++--
+ mats/Mf-i3osx | 4 ++--
+ mats/Mf-i3qnx | 4 ++--
+ mats/Mf-ppc32le | 4 ++--
+ mats/Mf-ta6fb | 4 ++--
+ mats/Mf-ta6le | 4 ++--
+ mats/Mf-ta6nb | 4 ++--
+ mats/Mf-ta6ob | 4 ++--
+ mats/Mf-ta6osx | 4 ++--
+ mats/Mf-ti3fb | 4 ++--
+ mats/Mf-ti3le | 4 ++--
+ mats/Mf-ti3nb | 4 ++--
+ mats/Mf-ti3ob | 4 ++--
+ mats/Mf-ti3osx | 4 ++--
+ mats/Mf-tppc32le | 4 ++--
+ mats/unix.ms | 4 ++--
+ newrelease | 22 +++++++++++-----------
+ pkg/Makefile | 2 +-
+ release_notes/gifs/Makefile | 6 +++---
+ release_notes/math/Makefile | 4 ++--
+ s/Mf-base | 2 +-
+ workarea | 10 +++++-----
+ 40 files changed, 101 insertions(+), 88 deletions(-)
+
+diff --git a/LOG b/LOG
+index e1631df..399104d 100644
+--- a/LOG
++++ b/LOG
+@@ -2119,3 +2119,15 @@
+ bintar/Makefile rpm/Makefile pkg/Makefile wininstall/Makefile
+ wininstall/a6nt.wxs wininstall/i3nt.wxs wininstall/ta6nt.wxs
+ wininstall/ti3nt.wxs
++9.5.5 changes:
++- avoid hard-coded paths for utilities in build scripts
++ checkin csug/gifs/Makefile csug/math/Makefile examples/Makefile
++ makefiles/Makefile-csug.in makefiles/Makefile-release_notes.in
++
This message was truncated. Download the full message here.
P
P
Philip McGrath wrote on 20 Mar 2021 17:06
Re: [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.
a4cbc2ec-be24-627b-fa53-866a3d8eb8f0@philipmcgrath.com
Hi,

On 3/16/21 5:09 PM, Leo Prikler wrote:
Toggle quote (11 lines)
> Am Dienstag, den 16.03.2021, 16:19 -0400 schrieb Philip McGrath:
>> On 3/16/21 3:37 AM, Leo Prikler wrote:
>>> Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
>>>> - (sha256 (base32
>>>> "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
>>>> + (sha256
>>>> "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
>>> You're inadvertently stripping away base32.
>>
>> I thought I'd read that explicitly calling base32 was redundant and

I think I'd conflated multiple things in my memory. I see that the
expansion of `package` applies the same special handling of the `sha256`
field for a literal string as one wrapped with `base32` (recognized with
`free-identifier=?`), including checking and conversion to a bytevector
at compile time.

Toggle quote (23 lines)
>>>> + ;; When there's a new tagged release,
>>>> + ;; go back to using (string-append "v" version)
>>>> + (commit
>>>> "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
>>> Could we then not cherry-pick this commit as a patch? Or is there
>>> more
>>> needed?
>>
>> We could, but the upstream history is simply v1.2.2 -> my patch ->
>> Kent
>> Dybvig's merge commit accepting it. I thought doing it this way
>> clarified that it's not a Guix-specific patch that should stay
>> around
>> indefinitely. Is there a reason to prefer cherry-picking it as a
>> patch?
> You'll probably hear differing opinions about that, and that's fine,
> but my personal reason to prefer cherry-picking would be, that it makes
> it very obvious, what changed from the base – that being the patch
> modulo offset changes – and doesn't invite people to go out saying
> "aha, but I found this commit and I like that more, let's take it". In
> other words, this is very subjective, but I believe we should stick as
> close to releases as is reasonable.

I can understand that perspective. From my point of view, I'm inclined
to see the release plus one upstream commit (the first commit since
2017) as closer to the release than a free-floating patch file: with a
patch, I can see what has changed, but I need to evaluate why it was
changed, if the change is still necessary, and so forth, rather than
relying on the upstream maintainers' judgement.


Toggle quote (4 lines)
> I don't think we can necessarily trust the boot files in this
> configuration. "They are bit-for-bit identical" can also mean, that
> the login() hack was successfully applied for all you know.

Yes, the "trusting trust" issues are especially striking if you consider
that Chez Scheme was non-free software from 1984 to 2016, and the first
libre release likewise needed the bootfiles of its ancestors.

My point here was just to save space, from the perspective that these
are build artifacts which can be easily recreated by anyone on a
GNU/Linux system. But I don't think it's especially important, so I'm
keeping them.

I hope it might turn out to be possible eventually to bootstrap via
Racket, maybe even by just picking an older version of the bootstrap
code before the Racket fork's #!base-rtd gained a vector of ancestors
rather than a parent and a few such things, but I think there's more to
be done around Racket packaging before investigating that.

-Philip
L
L
Ludovic Courtès wrote on 5 Apr 2021 12:02
Re: bug#47153: [PATCH] gnu: chez-scheme: simplify packaging
(address . 47153@debbugs.gnu.org)
87h7klujzr.fsf_-_@gnu.org
Hi Leo,

If this v3 looks good to you, please push. :-)

One nitpick:

Philip McGrath <philip@philipmcgrath.com> skribis:

Toggle quote (3 lines)
> - (sha256 (base32 "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
> + (sha256 "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")

Before pushing, please keep the (base32 …) forms (here and elsewhere).
That they can be removed is not intended.

Thanks Leo and Philip,
Ludo’.
L
L
Leo Prikler wrote on 5 Apr 2021 16:20
(address . 47153-done@debbugs.gnu.org)
034cdb2bde4247d5a4124017f2204a87106bc293.camel@student.tugraz.at
Am Montag, den 05.04.2021, 12:02 +0200 schrieb Ludovic Courtès:
Toggle quote (3 lines)
> Hi Leo,
>
> If this v3 looks good to you, please push. :-)
Ah, sorry. I totally missed v3, because I wasn't CC'd.

Toggle quote (13 lines)
> One nitpick:
>
> Philip McGrath <philip@philipmcgrath.com> skribis:
>
> > - (sha256 (base32
> > "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
> > + (sha256
> > "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
>
> Before pushing, please keep the (base32 …) forms (here and
> elsewhere).
> That they can be removed is not intended.
>
Done and pushed.

Regards,
Leo
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 47153@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47153
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch