ruby port group: prepare for ruby 1.9

[febeling@…]

Enhance the ruby.setup command so that it takes an additional optional argument implementation which determines the ruby-implementing port. This can be ruby and ruby19 for now. This value determines the ruby binary to use for installation, which in turn makes values from rbconfig.rb active for the undergoing installation.

This parameter willl also determine the port name prefix. So far it is always "rb-", it will be rb for 1.8 ruby and rb19 for ruby 1.9, following the example of python port prefices.

[febeling@…]

test cases, put into subdir group/tests to run

[raimue@…]

Do we really need to split up the ports? It causes a lot of work for py-* and py25-* because we have no way to keep them in sync easily. So there are many python modules in the tree with different maintainers and different versions for py-* and py25-*.

I am not a ruby expert so I don't know if there is a need to keep ruby 1.8 and ruby 1.9 around at the same time.

[febeling@…]

Replying to raimue@macports.org:

Do we really need to split up the ports? It causes a lot of work for py-* and py25-* because we have no way to keep them in sync easily. So there are many python modules in the tree with different maintainers and different versions for py-* and py25-*.

As much as I'd like to avoid this complexity, I'm still convinced that we need it. Depending on variables collected during build phase of ruby itself, the standard installers choose the library paths to install files into. And these paths contain the ruby version as one element. For 1.8 we have these paths:

/opt/local/lib/ruby/site_ruby/1.8
/opt/local/lib/ruby/site_ruby/1.8/i686-darwin9.2.2
/opt/local/lib/ruby/site_ruby
/opt/local/lib/ruby/vendor_ruby/1.8
/opt/local/lib/ruby/vendor_ruby/1.8/i686-darwin9.2.2
/opt/local/lib/ruby/vendor_ruby
/opt/local/lib/ruby/1.8
/opt/local/lib/ruby/1.8/i686-darwin9.2.2

(Kimuraw changed this lately to exclude minor and teeny version numbers, though, for the arch-dependent directories.)

For 1.9 we get these:

/opt/local/lib/ruby/site_ruby/1.9.0
/opt/local/lib/ruby/site_ruby/1.9.0/i686-darwin9.3.0
/opt/local/lib/ruby/site_ruby
/opt/local/lib/ruby/vendor_ruby/1.9.0
/opt/local/lib/ruby/vendor_ruby/1.9.0/i686-darwin9.3.0
/opt/local/lib/ruby/vendor_ruby
/opt/local/lib/ruby/1.9.0
/opt/local/lib/ruby/1.9.0/i686-darwin9.3.0

I am not a ruby expert so I don't know if there is a need to keep ruby 1.8 and ruby 1.9 around at the same time.

I think we do need both installed in parallel, because 1.9 is tagged somewhat "experimental", still people will try to use it productively to profit from it's increased performance. There is some ambiguity about all this so they will probablt co-exist for quite a while.

The change between 1.8 and 1.9 is rather big, and it comprises syntax changes as well as internal changes, see [1]. Even if you were to install libs always using ruby 1.8, 1.9 would not pick them up, at least not unless you patch that ruthlessly into the standard ruby behaviour. That would mean either we make 1.9 pretend it was 1.8, or we make both drop the version component of the paths. Both would mean asking for trouble, imho.

I would love to hear how we can avoid this. I looked at linux distributions and only debian/testing has ruby1.9 so far (as of 3 weeks ago or so). And they go the same route and prepare packages for 1.8/1.9 in parallel.

I'll add kimuraw as the ruby 1.8 maintainer to CC. Maybe he has some more insight/an opinion on this issue.

[1]  http://eigenclass.org/hiki/Changes+in+Ruby+1.9

[febeling@…]

patch to change ruby port group as described; fix a regression with gem type rbports

[febeling@…]

I have a script which uninstalls, cleans, and installs all ruby port for regression testing. Pre- and port results are now exactyl the same.

[febeling@…]

Committed as r38683.