RubyCocoa 0.11.1

Eloy Duran eloy.de.enige at gmail.com
Sat Jul 7 05:55:23 PDT 2007


Hello,

Took a while, before I had some time again to play with this...

First of, Ryan you were right that it was another port complaining
about the universal variant. It was rb-hpricot, I added
"universal_variant no" to the portfile which works great.

Also rubygems has a problem with the universal variant, I added the
following to the portfile to fix it:

variant universal {
	configure.args-delete --disable-dependency-tracking
}

Is this the correct way to do it?

One other thing I hadn't noticed earlier is that ruby itself does not
work with the universal variant. I could of course also add
"universal_variant no", but this will defeat the purpose of building
rubycocoa as a universal.... So does anybody know if ruby is already
being worked on?

On another topic, I haven't yet heard back from the maintainer of the
rubycocoa portfile. How do you guys deal with these kinds of issues?
Is there a period or so after which a new maintainer could step in?

Cheers,
Eloy

On 6/30/07, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jun 30, 2007, at 14:40, Eloy Duran wrote:
>
> > On 6/30/07, Ryan Schmidt wrote:
> >
> >> On Jun 30, 2007, at 09:48, Eloy Duran wrote:
> >>
> >> > Second, I'm not allowed to use the universal variant because
> >> it's not
> >> > a configure script based installation. Is there some way to
> >> override
> >> > this? Because now I have a builduniversal variant, but this is
> >> not so
> >> > nice...
> >>
> >> It should suffice to just redefine the universal variant:
> >>
> >> variant universal {
> >>    configure.args-append --build-universal=yes
> >> }
> >
> > Unfortunately it doesn't. Macports complains that the universal
> > variant is only supported on "configure" based ports...
>
> Don't forget to reply to all so that your reply goes to the list,
> too, and not just to me.
>
> Run the install in debug mode (sudo port -dv install). It's not
> complaining about your port; it's complaining about a different one.
> See my similar experience here:
>
> http://trac.macosforge.org/projects/macports/ticket/12170
>
> If you'll tell us which port it's complaining about, we can disable
> its universal variant like I did in #12137 for XFree86. That will
> work around the problem.
>
>



More information about the macports-dev mailing list