Two stage Ruby compilation / Bootstrapping

Hi all, Ruby upstream is implementing more and more stuff directly in Ruby. We already had issues, that build of Ruby required Ruby when we did some modifications [1]. In subsequent ticket, one of Ruby committers said [2]: depend on prelude one day. With recent changes, such as [3], I am afraid that the day has come. Previously, if you wanted to patch lets say "gem_prelude.rb", it was enough to patch it. But now you *need* Ruby to process it into miniprelude.c. There are possibly 4 ways out of this. 1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build Ruby using the previously built (mini)ruby. 2) Use previous version of Ruby available in Fedora to bootstrap Ruby. But this does not work ATM, at least when RubyGems are installed. And upstream is doing what they can to make RubyGems inseparable [4]. 3) Prepare patches locally and apply the required changes also to the pregenerated files. But the problem here is, that the patches might unpredictably fail between updates. I don't think that they keep any API/ABI promises for the tools used to generate those files. 4) Don't use the upstream tarball, but generate it from sources with patches integrated. I think we should probably start to take look at 1), specifically into the *miniruby* variant if that is enough. If that is done, the 2) could optionally blend in. And in the mean time use 3) because otherwise I really don't know how to integrate the ABRT hook support. I don't like 4) at all, unless we have some Fedora standardized way of doing so. On the positive side, 1(2) would allow us to stay better in line with "Pregenerated code" guidelines [5], because there is already quite a lot of pre-generated code shipped in Ruby release tarball. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c511... [2] https://bugs.ruby-lang.org/issues/15306#note-1 [3] https://github.com/ruby/ruby/pull/2655 [4] https://bugs.ruby-lang.org/issues/16431 [5] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...