Universal issues

[Jordan K. Hubbard]

On Jun 14, 2008, at 2:58 AM, Ryan Schmidt wrote:

> I think we should strive not to have this situation... if the port
> builds universal by default, an effort should be made to change the
> build so that it builds non-universal by default, and universal only
> when the universal variant is chosen. I know Anthony did this for
> many ports. For my ports that build universal by default I did not do
> this (sleepwatcher, and I just found out adtpro), and I should go
> back and fix this.

That would, unfortunately, invert you from the default scenario for  
all Apple projects (and I note this only because it can cause you  
special headaches when linking apps that expect all their frameworks  
and libraries to be universal by default, some of which may be  
provided by MacPorts) and also the default recommended to developers.   
Things should build universal unless there's a really good reason for  
them NOT to if you want to avoid confusion and anarchy.

I'm also kind of confused as to why this has been such a perennial big  
deal.  We have hundreds of OSS projects internally at Apple which  
build universal and the developer community at large has largely  
embraced universal builds for quite some time now - there are still  
problems here and there, sure, but I see a definitely trend towards  
those getting fixed as I see more and more stuff building universal  
with little to no modification.

I also know that there's the perceived problem of bloat (though  
storage is cheap and getting even cheaper) and general feelings of  
"why should I carry around the extra weight?", but that's short- 
sighted at best.  People buy new machines, they migrate their old apps  
and files using the Migration Assistant, and this is extra insurance  
for this case (instead of "aww, crap, now half of my stuff doesn't  
work!").  As previously noted, it's also REALLY important if your port  
builds a library or plug-in of any kind since you just don't know the  
downstream impact.  We have commercial software bundling in MacPorts  
and Fink bits all the time, as people have noted.

The only real issue I see is with x86_64 and Carbon apps, but that's  
more of an orthogonal porting issue that we (and developers in  
general) are going to need to grapple with regardless once that  
architecture becomes the default and Carbon gets more and more nails  
pounded in the coffin.

As to the value, and why we don't simply build everything i386/x86_64  
and let the ppc folks build their own bits or upgrade their way out of  
trouble, there is still value to Rosetta apps having various ppc  
libraries available, even if 100% of your user base has gone Intel, so  
I think 3-way universal (ppc, i386, x86_64) is still going to be of  
value for a number of years.

- Jordan