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 <kimu...@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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev