| Message ID | 5375de56eda0ee7c218ddf48da61ea600c0d2589.1651594312.git.philip@philipmcgrath.com |
|---|---|
| State | New |
| Headers | show |
| Series | gnu: Update Racket to 8.5 and Chez Scheme to 9.5.8. | 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 Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath: > * gnu/packages/chez.scm (stex)[arguments]: Run 'scheme' to determine > the machine type. How is this beneficial? What about cross-compilation?
Hi, On 5/4/22 02:58, Liliana Marie Prikler wrote: > Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath: >> * gnu/packages/chez.scm (stex)[arguments]: Run 'scheme' to determine >> the machine type. > How is this beneficial? At some high level of generality, there are two ways we could determine the machine type:* 1. We could predict ahead of time what it will be; or 2. We can ask the `scheme` executable we actually have. Trying to predict is easy to get wrong, because there's more than one possible machine type for a given system: currently that's true due to "--threads", and it will be even more true with "portable bytecode" back-ends. The `scheme` executable we're compiling with knows the definitive answer. This lets us remove the only use of 'nix-system->chez-machine'. > What about cross-compilation? I remembered this backwards; it should be `(#%$target-machine)` rather than `(machine-type)`. I'll fix that. But note that upstream stex does not support cross-compilation (though I hope to fix that one day). For example, both `Makefile` and `Mf-stex` contain: m := $(shell echo '(machine-type)' | $(Scheme) -q) (* To some extent there's an XY problem here: we don't care about the machine type per se, we care about the extension of intermediate object files we don't want to have installed, analogous to ".o" files. I think [1] upstream may have incidentally fixed the issues that made us build in that odd way, but it hasn't been part of a release yet. I plan to reevaluate before Racket 8.6, when we'll need [2] anyway to fix a bug exposed by Zuo.) -Philip [1]: https://github.com/dybvig/stex/pull/5 [2]: https://github.com/dybvig/stex/pull/6
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm index 785b6837c1..ea53cf5774 100644 --- a/gnu/packages/chez.scm +++ b/gnu/packages/chez.scm @@ -602,6 +602,10 @@ (define-public stex-bootstrap ("src" "lib/stex/") ("Mf-stex" "lib/stex/") ("Makefile.template" "lib/stex/")) + #:modules + '((guix build copy-build-system) + (guix build utils) + (ice-9 popen)) #:phases #~(modify-phases %standard-phases (add-before 'install 'patch-sources @@ -633,8 +637,12 @@ (define-public stex-bootstrap (define makefile (string-append (getcwd) "/Makefile")) (define machine - #$(and=> (nix-system->chez-machine) - chez-machine->threaded)) + (let ((pipe (open-pipe* OPEN_BOTH scheme "-q"))) + (write '(machine-type) pipe) + (force-output pipe) + (let ((sym (read pipe))) + (close-pipe pipe) + (symbol->string sym)))) (with-directory-excursion (search-input-directory outputs "/lib/stex") (invoke "make"