Re: Two stage Ruby compilation / Bootstrapping

[Pavel Valena]

----- Original Message -----
> From: "Vít Ondruch" 
> To: [e-mail]
> 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.
> > Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
> >
> > Ruby using the previously built (mini)ruby.
> > 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].
> > 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.
> > 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/c0513dfb8c81a228619c6142195c5117aa...
> >
> > [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-packag...