[26461] users/pipping/merge.rb

[Blair Zajac]

Weissmann Markus wrote:
> On 25 Jun 2007, at 11:37, Ryan Schmidt wrote:
> 
>> On Jun 25, 2007, at 03:47, Kevin Ballard wrote:
>>
>>> On Jun 25, 2007, at 1:41 AM, Weissmann Markus wrote:
>>>
>>>> Do you have any further information on unify.pl? Does it have a web 
>>>> page or some documentation? I wasn't aware of it neither and also 
>>>> missed your previous mails.
>>>> I do not expect though, that we are reinventing the wheel: The 
>>>> requirements that I'd expect Mozilla to have on such a tool differ 
>>>> quite a bunch to ours:
>>>> Mozilla knows what they are building and they know that both builds 
>>>> are "the same" stuff - we don't (e. g. some software may enable 
>>>> features on certain archs).
>>
>> If files are present in one tree but not the other, unify can be 
>> configured to either include or omit those files.
>>
>>>> We also do not only need to merge two binaries, we also need to test 
>>>> and merge different kind of files, like C header files, pkgconfig 
>>>> files, libraries, etc.
>>
>> unify handles this.
>>
> 
> I just had a look at unify.pl and I can't see how it e. g. handles 
> merging C-header files (this could e. g. be done with #ifdef arch) or 
> pkgconfig files.
> 
> 
>>>> I'd expect the actual lipo-ing of binaries to be the smallest part 
>>>> on Elias' tool - if that's what unify.pl is doing, I see no problems.
>>>>
>>>> I'd be happy for more information on unify.pl - searching the net I 
>>>> don't find anything. :/
>>
>> Just download the script and try it out, or read its documentation at 
>> the top of the script.
>>
>>> Unify takes two trees and merges them into one. Where the trees 
>>> differ, if it's an object file it lipo's them together, otherwise it 
>>> omits the file from the result (because there's no way to reliably 
>>> merge differing non-object files - how can you guarantee that 
>>> whatever way you choose to merge will actually work?).
>>
>> If non-object files differ in the two trees, unify exits with an error 
>> code.
>>
> 
> Well, I really think that the needs of the Mozilla people are quite 
> different to ours: They know both trees, they do not need to cope with 
> different programming languages, header files, etc.
> I also couldn't find it handling other archs than ia32 and ppc32 - after 
> all we already have aa64 and ppc64 and perhaps we'll get arm32 (iPhone 
> ;) and what-do-I-know.
> 
> 
>>> I don't know offhand how to actually get unify.pl, but I know it's 
>>> part of Mozilla.
>>
>> I did not find a web page for it or a way to download it separately; 
>> at the time, I downloaded the Firefox source distribution and found 
>> unify inside.
>>
>> At the time I also couldn't find an online repository browser for the 
>> Mozilla repository, but I now found a copy of the unify script here:
>>
>> http://gnuzilla.gnu.org/fulltree/iceweasel-1.5.0.7-g2/build/macosx/universal/unify 
>>
>>
>> I verified that this is the same version of unify I downloaded 
>> earlier, whose filesystem modification date is March 21, 2006.
>>
> 
> Thanks a lot for the direct link - I think that having a look at 
> unify.pl can help us avoid some already solved problems. Though I still 
> think that just using unify.pl is not enough - we have a lot more things 
> to handle than unify.pl already can.
> 
> Making use of unify.pl would also get us into using MPL-licensed code 
> which will be a pain if we integrate merge into port.

How would that be?  We're not linking against a shell script, just using its 
output.  After all, gcc is GPL, we don't make the same claim on all the compiled 
binaries MacPorts generates.

Blair