ruby_select experimental implementation

[kimura wataru]

Hi Florian,

On Fri, 24 Apr 2009 08:52:48 +0200, C. Florian Ebeling wrote:
> On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru <kimuraw at macports.org> wrote:
>> I write experimental ruby_select for ruby186 and ruby18.
>> 
>>  http://trac.macports.org/browser/users/kimuraw/ruby_select
> 
> I will test it shortly and try to add the ruby19 aspects to it.
> Is it ok if I commit to your user space svn or do you prefer
> if I branch it off to my space?
> 
I'm welcome your commit to my svn space.

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

>> ruby_select make symlinks the above files at post-activate.
>> then, install ruby_select means existence of ${prefix}/bin/ruby 
>> (without suffix).
>> I expect this port become a meta port port:ruby.
> 
> Yes. We have to keep an eye on Bryan's point though, that the older
> ruby port and the new ruby18 do conflict and that it can break installs
> for the user if he does not upgrade (over which we have now control
> besides from advising via ui_msgs). See his mail:
> 
> http://lists.macosforge.org/pipermail/macports-dev/2009-April/008258.html
> 

ruby18 and ruby do not conflict. ruby18 do not have any install files
with same path from ruby port.

>> 
>> == 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.
> 
> I'm not sure we want to interchange libraries between 1.8
> and 1.9 transparently. If we don't want it, having a name
> ending in 18 might be better. That way 1.8.6 and 1.8.7+
> would share the name here, but not 1.9. Having the
> executables share the same name seems to be the
> important part to me anyway, not so much for makefile
> in extensions and such (where the lib name would matter).
> 

I agree.
Recently 1.8 (1.8.6 or later) and 1.9 keep same C-API for 
extension modules. I think most of C-libraries for ruby 1.8 works
with 1.9 as well as pure ruby libraries. But, it means some
libraries do not work.


-- 
kimura wataru