----- Original Message ----- > From: "Vít Ondruch" <[email protected]> > To: [email protected] > 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/c0513dfb8c81a228619c6142195c5117aa0d1228 > > > > [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-packaged/#_pregenerated_code > > > > _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
