guix-patches
[Top][All Lists]
Advanced

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

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]