ruby_select experimental implementation

[Rainer Müller]

kimura wataru wrote:
> I write experimental ruby_select for ruby186 and ruby18.
> 
>   http://trac.macports.org/browser/users/kimuraw/ruby_select

Will ruby19 be moved to ruby? Or what will happen to the existing ruby
port at all?

I would like to avoid the situation we created with python, where we
have only the versioned ports. Currently if you install many ports
dependencies will pull in all of python24, python25 and python26.
Something like this should be avoided. And maybe there should also be a
"default" python version.

I am not against providing multiple versions and allow switching, but we
should avoid creating a dependency hell where multiple available
versions are pulled in unecessary as happened for python.

> == ruby_select
> 
> sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.
>[...]

The select files should be part of the corresponding ports and not be in
ruby_select as it is for python. This avoids selection of a
non-installed ruby version.

You can use the select port group at
_resources/port1.0/group/select-1.0.tcl to set this up easily.

> == linking libruby
> 
> ruby_select introduce libruby.dylib. this file is a symbolic link for 
> libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes 
> LIBRUBYARG and so on.
> 
>   % ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'        
>   "-lruby18"
>   % ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
>   "-lruby"
> 
> so, port:rb-* links libruby.dylib and extension modules (.bundle)
> use ruby_select-ed libruby.

This sounds like you will not be able to install modules for a specific
ruby version while you can install multiple ruby versions at the same
time. Is this correct? If so, where is the sense in that?

Also, switching ruby around with ruby_select after installing some rb-*
ports could probably break these, right?

Rainer