Re: [26461] users/pipping/merge.rb
On Jun 24, 2007, at 08:57, source_changes@macosforge.org wrote:
Revision: 26461 http://trac.macosforge.org/projects/macports/changeset/26461 Author: pipping@macports.org Date: 2007-06-24 06:57:23 -0700 (Sun, 24 Jun 2007)
Log Message: ----------- initial upload of <merge.rb>
merge.rb is designed to merge two or more trees of single-arch destdirs into a single destdir of universal binaries.
Now, what it is this? You may recall I mentioned the "unify" script on the mailing list some time ago, which based on your description, does what your merge.rb script does. Why reinventing the wheel? http://lists.macosforge.org/pipermail/macports-dev/2007-March/ 000864.html http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html
Hi Ryan, Kevin, On 25 Jun 2007, at 06:48, Ryan Schmidt wrote:
On Jun 24, 2007, at 08:57, source_changes@macosforge.org wrote:
Revision: 26461 http://trac.macosforge.org/projects/macports/changeset/ 26461 Author: pipping@macports.org Date: 2007-06-24 06:57:23 -0700 (Sun, 24 Jun 2007)
Log Message: ----------- initial upload of <merge.rb>
merge.rb is designed to merge two or more trees of single-arch destdirs into a single destdir of universal binaries.
Now, what it is this? You may recall I mentioned the "unify" script on the mailing list some time ago, which based on your description, does what your merge.rb script does. Why reinventing the wheel?
http://lists.macosforge.org/pipermail/macports-dev/2007-March/ 000864.html
http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html
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). 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. 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. :/ Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/
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?). I don't know offhand how to actually get unify.pl, but I know it's part of Mozilla. -Kevin Ballard 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). 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. 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. :/
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
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'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.
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.
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. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
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...
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
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.
I agree, anything slated for base/ should stick with a language already present in base/ unless there's a very good reason to introduce another. On Jun 27, 2007, at 12:02 AM, Ryan Schmidt wrote:
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?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
participants (4)
-
Blair Zajac
-
Kevin Ballard
-
Ryan Schmidt
-
Weissmann Markus