[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49158] Add ruby-for-crystal.
From: |
Maxime Devos |
Subject: |
[bug#49158] Add ruby-for-crystal. |
Date: |
Mon, 21 Jun 2021 20:04:02 +0200 |
User-agent: |
Evolution 3.34.2 |
jgart via Guix-patches via schreef op ma 21-06-2021 om 16:19 [+0000]:
> Hi Guix,
>
> We've (Ryan, David, Raghav, and others) started packaging crystal for guix:
> https://crystal-lang.org/
>
> This patch adds an old version of ruby that is required by the crystal
> language bootstrap process. This is related to 49142.
>
> This was an effort of the volunteers at the last guix packaging meetup hosted
> by LibreMiami.
>
> Here are some notes, questions, and a list of dependencies regarding what is
> needed
> to finish a properly bootstraped crystal package:
>
> https://github.com/ryanprior/guix-packages/blob/master/testing/crystal.org
>
> We are trying to recreate this bootstrapping process in guix:
>
> https://github.com/crystal-lang/bootstrap-script
>
> There are 160 stages!
>
> Some questions extracted from our notes follow:
>
> Is it preferable to have 160 bootstrap packages, one for each stage,
> or one big bootstrap package with 160 build-* stages, or somewhere inbetween?
Definitely 160 separate bootstrap packages I'd say.
Though the first 159 wouldn't be exported and would be hidden.
Because:
(1) presumably, building all these different versions of crystal
would take a lot of time
(2) if the build process OOMS, if there is a build failure at some
stage, the user cancelled the build, and retried,
then ideally Guix wouldn't start rebuilding the previous stages
(3) so, 160 separate packages.
> How best can we use Guile macros to clean up the large amount of code implied
> by executing 160 stages of bootstrap logic?
There doesn't seem to be much reason to use
macro's here (except 'package' & 'define' itself)
Basically, you'd do something similar to what's already done
for Rust:
(define* (crystal-bootstrapped-package base-crystal version checksum commit)
"Bootstrap crystal VERSION with source checksum CHECKSUM and git commit COMMIT
using BASE-CRYSTAL"
(package
(inherit base-crystal)
(version version)
(source
(origin
(inherit (package-source base-crystal))
(commit commit)
(sha256 (base32 checksum))))))
To start the process,
define an initial version crystal-stage1 like you'd do for any other package.
Then, for each N+1, define
(define crystal-N+1 (crystal-bootstrapped-package crystal-N VERSION CHECKSUM
COMMIT))
Some crystals probably need somewhat different inputs, or require some fudging
in phases, so you might to occasionally modify the resulting package a little:
(define crystal-N+1
(package
(inherit crystal-N)
(inputs `(("stuff" ,libstuff)
,@(package-inputs crystal-N)))
And export the final version:
;; Don't forget to remove the 'hiddenness' from crystal-160!
(define-export crystal crystal-160)
> Each stage needs a different checkout of the git repository - can we preserve
> info in .git
> such that we can checkout again during the build,
The .git directory isn't bit-for-bit reproducible
(think different versions of git, different versions of compression
libraries, different parallelism levels, etc. causing a slightly
different pack), so no.
Also, falling back to Software Heritage wouldn't work.
> or do we want to have each checkout be an
> independent input to the package?
If you'll be using the 'crystal-bootstrapped-package' from above,
then you'll automatically get independent inputs.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part