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 <[email protected]> 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 > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Florian Ebeling Twitter: febeling [email protected] _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
