----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com>
To: ruby-sig(a)lists.fedoraproject.org
Sent: Tuesday, November 10, 2020 7:19:38 PM
Subject: Re: Two stage Ruby compilation / Bootstrapping
Wow, it has been year since I started this thread. Time flies.
But since I was fighting again with one revert, which was not possible
to do without boostrapping, I went ahead and now I have this PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/72
Looks Great!
Although I don't see any comment on
0001-Revert-Add-GC.auto_compact-true-false-and-GC.auto_co.patch
- The patch doesn't seem maintainable. (Am I wrong?)
- What it's exactly needed for? (Trim miniruby dependencies?)
This is the case (1) I have mentioned bellow. As you can see from the
patch, it turns out it is not that easy as I was expecting.
* Building `miniruby` target is not enough.
* Loading of dynamic libraries is not enabled by default in miniruby.
* There are required several extensions (ripper and stringio atm).
* There is required some script which acts as "ruby" to glue all this
together.
So based on the experience, I have several discussion topics:
* Is it worth of building miniruby with all this hassle? It could be
better to build "bootstrap-ruby" instead, which could be possible better
interchangeable with system ruby. IOW that would bring this closer to
the variant (2).
`ruby` project does not use any bootstrap, right? What specifically do you mean by
bootstrap-ruby? Is it RPM ~bootstrap?
Incidentally, ruby has `bootstraptest` folder with tests... I don't think it's
used for any regular build, but maybe we could use it for such bootstrapping?
* Not sure if the miniruby configure options changes a lot. I have the
feeling that the build system tries to pull in even the parts which
should be unused :/
* Would it be worth of cleaning up the "miniruby" directory, to have
more control about what could be used/included. I have diff of the stuff
which is in tarball and what is the minimal set of files required to
build miniruby at my hand, if anybody is interested.
Is upstream interested in such trimming? Seems like a worth-while thing to have. Or is it
not upstreamable?
So what did I miss? Of course I am interested in any feedback and
especially in suggestions for improvement.
Is there a build? simple-koji-ci does not seem to run, same for tmt CI.
Is there any testing we can do to help?
Thanks,
Pavel
Vít
Dne 20. 12. 19 v 17:26 Vít Ondruch napsal(a):
> 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]:
>
>> ... snip ...
>> BASERUBY is already a build requirement
>> ... snip ...
>> I would like to implement more of Ruby using Ruby, so miniruby may
> 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...
>
>