Just say no to +universal

[Landon Fuller]

On Mar 3, 2007, at 2:33 PM, Jordan K. Hubbard wrote:

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


I don't think it's reasonable to compare Apple's static manually  
managed B&I build system to MacPorts. We could also write shell  
scripts and Makefiles and random glue to build software, but we don't  
-- MacPorts, instead, requires ports to be declarative, and then  
takes care of the rest.

These are two different problem spaces. Apple, due to B&I's  
requirements, *needs* software to build universal on single systems.  
We don't, and there are arguably many benefits to not doing so, the  
greatest of which is reduced maintenance and implementation complexity.

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

Because the right place to fix this is in the upstream project's  
build, not as an add-on set of extensive hacks. It's admittedly not  
black and white -- if a project builds universal with a few CFLAG  
tweaks, and works fine under testing, then super! But blithely  
forcing software into the +universal universe just doesn't add up  
when there are only fringe benefits and *great cost* in terms of  
added complexity.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/0dfc38f4/PGP.bin