[26461] users/pipping/merge.rb

[Ryan Schmidt]

On Jun 25, 2007, at 05:09, Weissmann Markus wrote:

> On 25 Jun 2007, at 11:37, Ryan Schmidt wrote:
>
>> On Jun 25, 2007, at 03:47, Kevin Ballard wrote:
>>
>>>> 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.

Ok, sorry, you're right, I didn't mean that it merges headers; I  
meant that if the headers in the Intel and PPC trees are the same it  
would install them in the merged tree. I didn't consider that there  
might be differing header files by platform, and I didn't consider  
pkgconfig files.

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

True... The unify script does seem to merge two trees only, which is  
a limitation.

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

True, I was also concerned about what license issues we might run  
into. I do not know what the license implications are of using unify.  
If we decided we wanted to use unify, I'm sure we could ask the  
Mozilla folks for input.


So, the consensus seems to be that the merge.rb script is better for  
us than Mozilla's unify. That's fine. I'm just feeling a little irked  
and left out of the loop. I posted a message on this list two weeks  
ago with some suggestions for improvements to the universal syntax:

http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html

Nobody responded -- well, not to my actual suggestions, anyway. One  
of my suggested syntax additions dealt with merge/unify-like  
functionality -- functionality which would need to be added to base  
either using the unify script or a script written for MacPorts. It  
seems to me now that Elias has either coincidentally started working  
on this script, or has done so in response to my message. It just  
seems to me like in a community-driven project like MacPorts, we need  
to communicate with one another, let one another know what we're  
working on. And I'm a little unhappy that I haven't heard a word from  
Elias on this topic yet.

Elias, is your merge.rb script destined for inclusion in MacPorts  
base, for use by portfiles in some way? If so, then I'm a little  
displeased that you've chosen to write it in Ruby. I don't know Ruby.  
I know PHP, Bash, a bit of Perl, enough Tcl to get by with MacPorts,  
but not Ruby, nor was learning it on my agenda. Why introduce another  
programming language here?

It also would have been nice if you would have posted a short message  
to the list, letting us know that you're developing this, what  
features you're planning on adding, how it would work, etc., so that  
we might comment on it before you spend time doing work that we may  
disagree with. I don't know if I disagree with it, because I haven't  
looked at the code, because I don't know Ruby...

I don't mean to sound ungrateful for your work, I just think we need  
to coordinate and communicate better.