I haven't found a URL to do the checkout, but this works: $ cvs -d:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/build/macosx Then look for unify. Regards, Blair Elias Pipping wrote:

Could you hook me up with a link please?

Regards,

Elias Pipping

On Mar 6, 2007, at 7: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?

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.

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.