ruby_select experimental implementation

[C. Florian Ebeling]

Hi Kimura,

I just committed the ruby 1.9.1 parts to the ruby_select branch.
It works fundamentally now. Here are a number of things I have noticed:

- errors when no ruby whatsoever is installed. If a versin is not install
  but then selected, then user doesn't get a warning nor an
  error. This behaviour comes from select-0.2.1, I'm aware, but it's
  still a bit unintuitive.

- version suffix: ruby19 has the executable suffix 1.9 (with dot),
  ruby18 has 18 (without dot) -- not quite consistent. With ruby19 I
  have adopted this scheme (name without dots, executable with dots)
  from mp python ports. I would suggest you consider switching to
  suffix "1.8" and "1.8.6" as well, for the sake of consistency (also
  since the suffixes for 1.8 rubys are not out at the users yet) Would
  that be acceptable to you?

- symlinked libs: I think this is not worth the trouble, and between
  1.8 and 1.9 it would even look a bit hazardous to me. Python does
  not try to do this, if I'm not mistaken, and the description of the
  ruby_select port also only mentions the interpreter (which we would
  need to extend to irb, ri, etc, anyway). I would leave them out for
  simplicity :) Would you mind?

- rake1.9, gem1.9: Not sure what to do with rake1.9 and gem1.9. These
  should be accessible via their basename as well, but we probably
  don't want separate rake_select and gem_select ports. The fundamental
  idea is that 1.8 and 1.9 can stay installed and active, while keeping
  the simple 'ruby', 'irb',
  etc. invokations. But when can neither easily add them to the
  collection of executables we switch here, since they don't come with
  a suffix, nor can I just add symlinks to the ruby19 port, since then
  it would conflict with rb-rubygems and rb-rake. (Perhaps still
  the best would be to accept that rb-rubygems/rb-rake and ruby19 do
  conflict and tell users to deactivate them for them time being.)
  Please tell me if you have an idea for that or what you would
  prefer.

I haven't thought about the renaming of port ruby to ruby18 yet, but
we would have to have something for that as well before this whole
patch can go into trunk.

Florian


On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru <kimuraw at macports.org> wrote:
> Hi,
>
> I write experimental ruby_select for ruby186 and ruby18.
>
>  http://trac.macports.org/browser/users/kimuraw/ruby_select
>
> == 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.
>
> == 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.
>
> == 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 implementation is not enough. please tell me your thoughts.
>
> --
> kimura wataru
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



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