RubyCocoa 0.11.1

[Eloy Duran]

Totally offtopic but good to say I think:
Ryan thanks for all your good and also fast replies and help!
Macports totally rocks thanks to people like you :)
Of course this counts for all the others on the team too!

Eloy

On 7/17/07, Eloy Duran <eloy.de.enige at gmail.com> wrote:
> Hello,
>
> > > Should I create a symlink in pre-build like:
> > > $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt
> > > And then remove it in post-build?
> > >
> > > Or should this be created at installation time of macports?
> > > Because like you said, that search yields a lot more than one
> > > result....
> >
> > MacPorts should not be modifying things outside of /opt, certainly
> > not the contents of a Mac OS X SDK. This is a workaround, not a real
> > solution.
>
> The solution was rather simple, I had to simply omit the sysroot flag.
> Ruby uses only dependencies that are build with macports, so the flag
> isn't necessary anyway.
>
> I have now submitted a patch that adds universal support to the ruby port.
> http://trac.macosforge.org/projects/macports/ticket/12314
>
> >> And like I hoped all gems are being build with the config that ruby
> >> was build with.
> >> So hpricot from macports and libxml from rubygems both build universal
> >> extensions :)
> >>
> >> So all the ports that are rubygems based, should they by default have:
> >> "universal_variant no"? Because they will be build in the same manner
> >> as ruby was build nonetheless.
> >
> > If there is something that needs to be done in all the ruby ports,
> > then it should not be done in all the ruby ports, but instead in the
> > ruby portgroup.
>
> Understood, I've submitted a patch which adds "universal_variant no"
> to all gem based ports.
> http://trac.macosforge.org/projects/macports/ticket/12317
>
> I have also submitted a patch that adds "universal_variant no" to rb-rubygems.
> http://trac.macosforge.org/projects/macports/ticket/12318
> (I accidentally marked it as a defect instead of an enhancement.)
>
> Now the last patch I have is the one for rubycocoa itself.
> But first I would like to now if it's allowed to change the name of the port?
> Because the name of the software is rubycocoa not cocoa....
>
> Also I saw today that building from a clean macports installation with
> the universal variant now breaks at the point where perl is being
> build (for autoconf?). I must have been sleeping last time I checked
> (about 2 weeks ago), but I could have sworn it didn't fail back then.
> But actually more important, perl doesn't build as a universal. So
> should I tell my users to tell port to build rubycocoa as a universal
> and expect it to break at the point of perl, then tell port to build
> perl as a non-universal and afterwards again tell port to build
> rubycocoa as a universal?? This doesn't really feel ok.....
>
> Cheers,
> Eloy
>