Just say no to +universal

[Jordan K. Hubbard]

On Mar 3, 2007, at 1:09 PM, Landon Fuller wrote:

> I agree. It's not that universal builds are a bad idea; it's that  
> supporting universal software requires serious bastardization of  
> Portfiles in most cases. Assuming we implement some sort of binary  
> distribution, I'd personally much rather use the approach that fkr  
> and shantonu used for supporting Darwin x86 and PowerPC -- build  
> the software on each system, natively, and then join the resultant  
> RPMs into a single fat RPM.

I think this may have gotten lost in all my earlier verbiage, but I  
also pointed out early in the conversation that there are many many  
open source projects building universal at Apple without such  
"bastardization".   The Makefile for OpenSSL is just 147 lines, for  
example, and of that at LEAST 50% has to do strictly with Apple's own  
requirements (the whole SRCROOT and DSTROOT thing, order files, all  
the things you probably still have nightmares about from time to  
time).  Perhaps 5 lines in the Makefile are devoted to the fact that  
it's building universal.

The rest is in the "generic machinery" and helper scripts (which,  
you'll instantly notice, have a lineage dating back to 10.1) like  
this one:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ar.sh
Type: application/octet-stream
Size: 1852 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/fe73dcbc/ar.obj
-------------- next part --------------

This gets used by the generic CoreOS Makefile machinery in place of ar 
(1), given a bit of metadata expressed in other parts of the build  
system.  Are lipo(1) tricks like this the best way to do it?  Not  
even saying that.  I'm simply saying that it's a fallacy to assume  
that OpenSSL, OpenVPN and hundreds of other ports are all going to  
need to grow universal variant rules as long and complex as the one  
you posted.  Just because someone hasn't templated that stuff and  
stuck it somewhere for every port to use doesn't mean it can't be  
done, and Apple's own open source projects are living proof of  
that.   I'm furthermore assuming that once a few more universal ports  
get done and the commonality in the rules starts to shine through the  
complexity, someone WILL sweep it into a pile and make it port- 
generic.  I can recall a time when darwin^H^H^H^H^Hmacports had a lot  
of pretty crufty Portfiles which, over time, got substantially less  
crufty as more primitives were added and consolidation mechanisms  
like PortGroup got added.

Why is everyone being so quick to slam pipping's changes before they  
even have a chance to go through an evolution or two?   I know there  
are still a few people here who still don't get the whole point of  
universal builds, or doubt their value to MacPorts, but that's  
orthogonal to the whole issue of "quality of implementation",  
something which has to at least be given a chance to improve before  
coming to any firm conclusions about it.

- Jordan