blair at orcaware.com
Mon Jun 25 10:39:33 PDT 2007
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
> 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:
>> 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.
More information about the macports-dev