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 <[EMAIL PROTECTED]> 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
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
