[bug#47153] [PATCH] gnu: chez-scheme: simplify packaging

[Philip McGrath <philip@philipmcgrath.com>]

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.

> 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.


> , also does this need to be done at the same time as the
> nanopass upgrade?

No

>> (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?

> 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.

>> +(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