2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog)

[Ryan Schmidt]

On Jan 17, 2008, at 11:08, Juan Manuel Palacios wrote:

> On Jan 17, 2008, at 12:14 PM, Eric Hall wrote:
>
>> On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote:
>>
>>> On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote:
>>>
>>>> Ryan Schmidt wrote:
>>>>
>>>>>> Also, it would be more "universal" if it was to use the 10.4u SDK
>>>>>> on Leopard too, since then the generated binaries would work on
>>>>>> Tiger in addition. (currently it uses the 10.5 SDK if available)
>>>>>
>>>>> Yes, but I understood that it was changed to use the 10.5 SDK on
>>>>> Leopard because using the 10.4u SDK on Leopard was broken?
>>>>
>>>> No, the usage of it was broken. It wasn't setting
>>>> MACOSX_DEPLOYMENT_TARGET (to use 10.4)
>>>>
>>>> "ld: library not found for -lcrt1.10.5.o"
>>>>
>>>> Changing to the 10.5 SDK made the problem "go away", since it would
>>>> work with M_D_T=10.5
>>>
>>> Oh I see! Then yes, by all means, we should use the 10.4u SDK and  
>>> set
>>> MACOSX_DEPLOYMENT_TARGET to 10.4.
>>
>> 	Mmm, this sounds like the idea is "build for Tiger if we're
>> on Leopard" even if the user will never use the ports on Tiger.
>> What's being given up by using the 10.4 SDK instead of 10.5 (i.e.
>> what fixes, enhancements, etc.)?
>> 	If there's no real difference, fine.  If there is a difference,
>> I think it should be an option for those who are going to build on
>> Leopard and share with Tiger systems, otherwise use the platform- 
>> native
>> SDKs.
>
> 	Seconded all the way!
>
> 	We could have macports.conf settings for both, a) the OS's the  
> users wishes to build for, Leopard and/or Tiger and/or Panther, and  
> b) the desired architectures, Intel and/or PowerPc and 32 and/or 64  
> bits. But in the mean time, while we still don't have that level of  
> abstraction (we don't, right?), it seems more logical to me to  
> build as native as possible. Now, universal advocates, hold your  
> horses! I'm not arguing against universal support itself; I am  
> arguing, though, against universal support hampering in any way  
> native builds, which I'm positive is what a considerable majority  
> of MacPorts users do and need.

The SDK is only used to build a universal binary, when using the  
+universal variant. The only users who will be using that option are  
those who by definition want to share the binary with other machines.  
Ok, maybe they want to share the binary only between Leopard  
machines. But I still think it's a relatively safe assumption to use  
the 10.4u SDK when building a universal binary. Until we start having  
ports for Leopard-only applications...

As it is now, a port built +universal on Leopard is different from a  
port built +universal on Tiger, and that tastes wrong. But maybe  
that's just the way it has to be? What will happen when we get binary  
packages of ports? Will we have to have separate binaries for each  
cat? I guess maybe we will. We already have the problem that ports  
built +universal on Tiger won't be usable on Panther, so we'd need  
separate binaries for Panther anyway.