Universal ports: mozilla's unify script

[Ryan Schmidt]

On Mar 9, 2007, at 20:39, Kevin Ballard wrote:

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

Ok. That situation happened to me several times when playing with it.  
In that case, the script prints an error message and exits. Such  
situations must be resolved before running the unify script.