Universal Binaries

[Jordan K. Hubbard]

On Feb 23, 2007, at 11:36 AM, Ryan Schmidt wrote:

> Now, what we could think about doing is providing some kind of  
> default, where +universal would use the standard CFLAGS, LDFLAGS  
> and --disable-dependency-tracking, unless the port itself defines a  
> +universal variant. This would allow many ports to build universal.  
> However, those for which is doesn't would then be broken. Either  
> building with +universal would cause compilation or configuration  
> errors, which the user could then report to the maintainer, or the  
> software would seem to compile and build properly, but then not  
> actually run properly on the non-native architecture. It's hard to  
> know until you try it, separately for each software package.

I think this is a good idea.  Yes, software will break, but if you  
make it a goal to build everything universal, it will also quickly  
get fixed and then you're over the hump and don't have to think about  
it anymore.   Getting this done will also make the 32->64 bit Intel  
shift easier to deal with since you want to build i386/x86_64  
versions universal as well (running apps as 64 bit on Core2 Duo  
systems is starting to become more attractive due to the extra  
registers you get and, of course, the larger address space).  That's  
probably not a short-term goal, but it's somewhere on the horizon and  
this is one more step in the right direction.

As I said before, Apple has already gone through this for hundreds of  
apps and it's not as painful as many people think.  A consistent  
build harness like MacPorts makes it even easier, since you can deal  
with issues like broken configure scripts (which make static  
determinations of endian-ness or arch) by post-processing their  
output before starting the build phase.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070223/8ac9b01b/attachment.html