Universal ports: mozilla's unify script

Kevin Ballard eridius at macports.org
Fri Mar 9 18:39:55 PST 2007

On Mar 9, 2007, at 9:33 PM, Ryan Schmidt wrote:

> On Mar 9, 2007, at 20:15, Kevin Ballard wrote:
>> On Mar 6, 2007, at 1:56 AM, Ryan Schmidt wrote:
>>> If we're serious about universal binaries, the mozilla project's  
>>> unify script is useful. Install once for ppc to a given path,  
>>> install a second time for i386 to a different path, then call  
>>> unify, telling it where your ppc and i386 builds are, and it  
>>> combines them into a new third tree, using lipo on any files as  
>>> needed.
>>> If you can build without using lipo, great, but if you need lipo,  
>>> then unify is a time saver, not having to engineer all that logic  
>>> again of figuring out what needs to be lipo'd.
>>> Now it's just a question of licensing, and I'm no expert in that.  
>>> Is it possible to take the unify script from mozilla and  
>>> incorporate it nicely into MacPorts? Are our respective licenses  
>>> compatible for that kind of inclusion?
>> I don't know the license of the script, but it is useful. The only  
>> thing to be careful of is if building ppc vs i386 produces  
>> differing outputs aside from executables/libraries - if unify  
>> finds a file differs in the two trees, and it's not an executable/ 
>> library, it ditches it entirely (since it doesn't know which input  
>> file to preserve in the output, and it can't lipo them together).  
>> This tends to be the case of a header file which is, say,  
>> processed with ./configure and differs based on the flags used for  
>> ppc/i386 building. Not a common occurrence, but entirely within  
>> the realm of possibility.
> I read that if there is a file that is only in the ppc or i386 tree  
> but not the other, then the default is for the unify script to copy  
> the file to the destination tree. There is an option you can pass  
> to the script if you would prefer that it not copy the file.

That's probably true, but I was talking about a file that existed in  
both trees, but differed.

Kevin Ballard
eridius at macports.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070309/a982a928/attachment.html

More information about the macports-dev mailing list