RubyCocoa 0.11.1

[Eloy Duran]

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