Universal and binary builds (was: Re: Is isysroot useful for non-universal?)

Ryan Schmidt ryandesign at macports.org
Mon Mar 23 18:43:02 PDT 2009


On Mar 23, 2009, at 18:01, Jeremy Huddleston wrote:

> On Mar 23, 2009, at 15:12, Ryan Schmidt wrote:
>
>> I would want (at least) one build server for each OS and processor  
>> combination, but if we began with just a single Intel Leopard  
>> machine, that would cover the majority of users. If we add a  
>> corresponding PowerPC Leopard machine, then we could do something  
>> interesting: Once the Intel and PowerPC builds are sent to the  
>> download server, the download server could combine both builds  
>> into a single universal binary package.
>
> Why put it on the back of the download server?  Let the user handle  
> this.  That way if we support n differnet architectures, we just  
> need to host n files (one tarball for each arch) instead of n!  
> files (one tarball for each combination).  With ppc, ppc64, i386,  
> x86_64 that's 4 versus 24 files which would probably be about 10x  
> storage space required (just a rough estimate considering that the  
> combined packages will be larger than the individual ones)

My motivation for suggesting that was that most packages include  
shared files which are arch-agnostic and I didn't want the user to  
have to download those shared files twice.

I should have also mentioned that some ports may still need to  
include merging instructions. Compiled things can be merged with  
lipo, but headers and other text files may also differ and may not be  
mergeable with diff. The muniversal portgroup offers solutions for  
this but the port must indicate for which files those other methods  
should be employed.

I meant to also mention that it would still be up to the user to  
decide which architectures they wanted to have installed.


>> It would use lipo, probably assisted by the code we have in the  
>> MacPorts merge procedure or the muniversal portgroup. It would  
>> avoid the above problems with our existing universal variants  
>> because the configure phase would run once for each processor, on  
>> that processor. We wouldn't need to deal with SDKs anymore. (I've  
>> never been comfortable with the idea of allowing the user to  
>> specify an SDK in macports.conf, so I don't see it as a problem  
>> that that would not be accommodated by our binary builds.)
>>
>> Using the above, we would have stable 32-bit universal binaries.  
>> We would also want each build server to separately build 64-bit  
>> versions. Obviously the build servers would be 64-bit machines.
>
> This just needs 2 build servers per OS version.

Exactly.

> Setup a ppc chroot on the ppc64 box and an i386 chroot on the  
> x86_64 box.

Sure.

> Since rosetta doesn't handle ppc64, we can't narrow this down to a  
> single x86_64 box.

We can't narrow it down to a single Intel Mac per OS anyway because  
one of the problems is that some software doesn't cross-compile  
correctly. The point is to eliminate the need for cross-compiling by  
compiling natively on each type of Mac.




More information about the macports-dev mailing list