Ruby ports and 1.9

kimura wataru kimuraw at
Sun Jul 13 04:00:59 PDT 2008

Hi Florian,

It's a very interesting plan!
But I think that is better to separate rb-* and rb19-* for some reasons.

* Ruby 1.9 is not stable version. I think 1.8 is still needed
  for daily work on 1.9 installed environment.
* So, it is important we can install, upgrade, uninstall rb-* and rb19-*

I have an inspiration from your email and ticket.
This feature makes easy to write rb19-* portfiles.

like this,

  % port cat rb19-rails
  PortSystem 1.0
  PortGroup  ruby 1.0
  ruby.import rb-rails 1.9

The proc ruby.import reads rb-rails Portfile (for 1.8)
and process portfile with Florian's extension for 1.9 (#15912)
and modify some attributes of the original portfile dynamically.

  name: rb-rails -> rb19-rails
  depends_lib: ruby, rb-rubygems, rb-rake, ...
            -> ruby19, rb19-rubygems, rb19-rake, ...
  configure.args-append --program-suffix=1.9

We can generate almost of rb19-* portfiles with a short script,
if this approach is available.

On Wed, 9 Jul 2008 00:43:05 +0200, Caspar Florian Ebeling wrote:
> Hi,
> Yesterday, I have put a patch for ruby group into the trac, which changes
> the ruby.setup command so that it accepts an additional parameter.
> With it applied
> ports for ruby19 can be installed using the port group. These would get
> a prefix of rb19 instead of rb, following the python example. Find it here:
> Rainer raised the concern, that these version-specific ports are a bit of
> a duplication, and that the experience with python was not really spotless.
> See his comment in the ticket. I see this problem as well.
> I have other issues myself. It is not entirely convincing to install
> ruby libraries
> via a generic package manager like mp, given that ruby has it's own in the
> form of Rubygems, which even comes builtin with 1.9.
kimura wataru

More information about the macports-dev mailing list