RubyCocoa 0.11.1

[Ryan Schmidt]

On Jul 7, 2007, at 07:55, Eloy Duran wrote:

> On 6/30/07, Ryan Schmidt 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...
>>
>> 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.
>
> 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.

Ok, so either "universal_variant no" should be added to the rb- 
hpricot port, or the rb-hpricot port should be fixed so it can build  
universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot.


> 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?

No. You have effectively made the port no longer attempt to build  
universal by doing that. Remember: when you write "variant universal  
{...}" in your portfile, you are *replacing* the default universal  
variant, which reads:

variant universal {
	if {[tbool use_xmkmf] || ![tbool use_configure]} {
		return -code error "Default universal variant only works with ports  
based on configure"
	}
	configure.args-append ${configure.universal_args}
	if {![file exists /Developer/SDKs/MacOSX10.4u.sdk/]} {
		return -code error "MacOS X 10.4 universal SDK is not installed  
(are we running on 10.3? did you forget to install it?) and building  
with +universal will very likely fail"
	}
	configure.cflags-append ${configure.universal_cflags}
	configure.cppflags-append ${configure.universal_cppflags}
	configure.cxxflags-append ${configure.universal_cxxflags}
	configure.ldflags-append ${configure.universal_ldflags}
}

See portmain.tcl:

http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ 
port1.0/portmain.tcl


The various universal_*flags are defined thus:

default configure.universal_args		--disable-dependency-tracking
default configure.universal_cflags		{"-isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -arch i386 -arch ppc"}
default configure.universal_cppflags	{}
default configure.universal_cxxflags	{"-isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -arch i386 -arch ppc"}
default configure.universal_ldflags		{"-arch i386 -arch ppc"}

See portconfigure.tcl:

http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ 
port1.0/portconfigure.tcl


What you probably want instead of "variant universal {...}" is:

pre-configure {
	if {[variant_isset universal]} {
		configure.args-delete --disable-dependency-tracking
	}
}

That's assuming, of course, that it's really necessary to remove "-- 
disable-dependency-tracking". The reason it's there by default for  
+universal is that it's needed for most (all?) configure-based  
software when building universal.

Now, rb-cocoa is in the ruby portgroup. These changes you're making  
to make it universal... might they also be relevant for the other  
ports in the ruby portgroup? If so, perhaps your changes, once you  
figure out how to build a ruby thing universal, should go into  
MacPorts base, rather than into each individual ruby-related portfile.


> 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?

No idea. Have you already asked Paul? He's also the maintainer of the  
ruby port. Also, have you already built all of Ruby's dependencies  
universal? That would be the first required step.


> 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?

The policy is that if you have changes you want made to a portfile,  
you file a ticket in Trac and attach a diff and assign it to the  
maintainer (if in the list) and Cc yourself and the maintainer. If  
the maintainer does not react within 72 hours, then you can email the  
list with the ticket number and request that someone else commit the  
change.