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

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hi!

Am Montag, den 15.03.2021, 14:03 -0400 schrieb Philip McGrath:
> 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 😉

> > 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" 🙂

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

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

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

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

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

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