ruby_select experimental implementation

[C. Florian Ebeling]

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?

>
> == install destinations
>
> * different name for ruby bundled commands and libraries
> * share library and document directory for additional libraries
>
> this allows to activate both of ruby186 and ruby18.
>
>
>  dir,file       1.8.6(ruby186)             1.8.7(ruby18)
> ------------------------------------------------------------
> bin/ruby        bin/ruby186                bin/ruby18
> bin/irb         bin/irb186                 bin/irb18
>  :
> libdir          lib/ruby/1.8.6/            lib/ruby/1.8.7/
> sitedir         lib/ruby/site_ruby/1.8/    (share)
> vendordir       lib/ruby/vendor_ruby/1.8/  (share)
> libruby.so      libruby186.dylib           libruby18.dylib
> ri sysdir       share/ri/1.8/system1.8.6/  share/ri/1.8/system1.8.7/
> ri sitedir      share/ri/1.8/site/         (share)
> ------------------------------------------------------------
>
> macports' vendor-specific.rb and site-specific.rb are moved
> to lidir from vendordir and sitedir to avoid conflicts.

That's what I expected, only these remaining conflicts
I didn't expect.

>
> == ruby_select
>
> sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.
>
>  % sudo ruby_select ruby18
>  Selecting version "ruby18" for ruby
>  % ls -l /opt/local/bin/ruby
>  lrwxr-xr-x  1 root  admin  21 Apr 18 21:03 /opt/local/bin/ruby@ -> /opt/local/bin/ruby18
>  % sudo ruby_select ruby186
>  Selecting version "ruby186" for ruby
>  % ls -l /opt/local/bin/ruby
>  lrwxr-xr-x  1 root  admin  22 Apr 18 21:06 /opt/local/bin/ruby@ -> /opt/local/bin/ruby186
>
> the following files are targets of ruby_select.
> * bin/ ruby, erb, irb, rdoc, ri, testrb
> * lib/ libruby.dylib, libruby-static.a
>
> 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

>
> == 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).

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com