Hi Slavek!
Great effort, although I did not have a chance to test your packages
yet, since I am busy with getting Rubinius in shape ;)
My general interest are the naming conventions. It seems that you are
going to use
* "j" prefix, such as jgem or %{jgem_extdir}
* -java suffix, for jruby subpackage
* jruby subdirectory for extensions
But I would suggest to always use suffix instead and for consistency, I
vote for "{-,_}jruby". E.g. you would get gem-jruby,
%{gem_extdir_jruby}, json-jruby and finally %{_datadir}/gems/jruby. Note
that I am afraid that the -java suffix becomes problematic in case, when
one day there will be introduced other alternative implementation of
Ruby in Java
For Rubinius, we would go either with -rubinius suffix, or -rbx, which
is shorter. However, there might be some complications with
%{gem_extdir_rubinius}, since ATM, it seems that binary extensions
compatible with Rubiniuses 1.8 mode are not compatible with Rubiniuses
1.9 mode (but I hope I am wrong).
And one more comment about the jgem. I am asking myself if that is good
idea to provide such jruby specific executables (although jgem might be
good candidate for exception), since it would imply that every gem has
to have its executable for different Ruby implementations etc. However,
I believe, that user is not interested which interpreted is used to
execute his program, as long as he gets the result. Therefore, the
distinction between gem and jgem is just implementation detail IMO and
should not be exposed, (but I might be proven wrong ;).
Vit
Dne 8.10.2012 15:44, Bohuslav Kabrda napsal(a):
Hi folks,
I'm writing a quick summary of what I managed to achieve with JRuby/Fedora
implementation so far. You can try out my repo at [1] and see the progress of
work on jruby.spec at [2].
- I have managed to remove the RubyGems copy from JRuby and make them work with
our system RubyGems - I had to apply few JRuby specific patches there - two are
already accepted upstream, but not merged into the 1.8 tree, one is still
pending [3]. The updated RubyGems are also in the mentioned repo and please be
careful when installing them, preferably use mock.*
- As a part of the RubyGems modifications, I have also prepared a sample gem
(rubygem-json, also in the repository), with a rubygem-json-java subpackage,
that provides Java extensions for JRuby.
- Pure Gems from Fedora now work with JRuby out of the box, no modification
needed.
- "jgem" command works exactly as "gem", only using JRuby - nice, isn't it? :)
- load paths set has been brought much closer to MRI, which allowed most of the
stuff I have done
TODO:
- I'm still unsure what is the best way to set up the Provides/Requires, so
that RubyGems would be installable without MRI, only with JRuby. I guess we can
live with JRuby dragging in Ruby, that's a small problem for now :)
- Some modifications to Guidelines will be needed, explaining how to build
Gems/non-Gems for JRuby.
- I will also add a jruby-devel package with macros.jruby to match MRI's
behaviour closely.
* The reason for this is, that I have also tried to introduce new naming scheme for Gems
extensions dirs, which is not compatible with the current one. So far, the %gem_extdir
was "/usr/lib[64]/gems/exts". With Rubinius and JRuby comming, there is a
slight problem - extensions for JRuby should of course go under /usr/share/gems/exts, but
Rubinius extensions would have problems, as they should go under %gem_extdir, too.
Therefore, I'd like to propose this scheme for extension placement:
%gem_extdir %{_libdir}/gems/ruby # MRI
%xgem_extdir %{_libdir}/gems/rubinius # Rubinius, not sure if that should be named
"xgem_extdir", what do the others think?
%jgem_extdir %{_datadir}/gems/jruby #JRuby # JRuby
This logic to implement this is very simple and it all goes to
defaults/operating_system.rb in the updated rubygems package in my repo
(specfile is a bit adjusted, too).
There is also a question of versioning these dirs, mainly Rubinius exts, but
I'm leaving that for future, comment if you have any good ideas :)
Thanks goes to Charles Nutter for taking the JRuby RubyGems close to upstream,
which was very important from Fedora integration POV :)
Slavek.
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
