On Apr 14, 2007, at 22:43, Elias Pipping wrote:
On Apr 15, 2007, at 5:36 AM, Ryan Schmidt wrote:
Recall the "unify" script from the Mozilla project, which they use to create universal binaries of Firefox and other programs from a ppc tree and an i386 tree, and my suggestion some time ago that it might be a good idea to incorporate it into MacPorts. Would that be a possible solution to your problem, without having to reinvent that script in tcl?
I do,
it wasn't written in tcl though (iirc).
Right, it's not; my point was that I hope you're not trying to write routines in tcl that do the same thing as unify *just because* unify isn't in tcl [1]. I say unify is a mature and useful script, and if its license is compatible with ours (research still needed here), why not make use of it in MacPorts, regardless of what language it's in. Now, if unify is insufficient for our needs in some way, then that may be another story. But even then perhaps we should be thinking "Can I make a minor change to unify so it does what I want?" rather than "Can I write a whole new script that does what I want?" I think I'm trying to suggest that maybe unify should be part of MacPorts base, and that MacPorts base should provide a way to configure and build a port separately for each architecture, then unify it into a universal binary, with very little effort from the port author. One option would be for this mechanism to become the default way that a universal port is built. The advantage would be that we can use an earlier gcc and an earlier Mac OS X SDK for the ppc build, making it compatible with earlier Mac OS X versions on ppc. We could introduce new variables by which port authors can specify the Mac OS X version that should be used for each architecture. This would be used to set the MACOSX_DEPLOYMENT_TARGET variable correctly, to select the right Mac OS X SDK to use, and maybe even to pick the version of gcc. Or if support of differing Mac OS X versions for the ppc and i386 builds is not a goal we want to pursue, then the multiple-build-and- then-unify approach could be a secondary way to build universally which the port author could request in the case that the normal quick -arch ppc -arch i386 universal variant we have in trunk now doesn't work with a given software package (openssl, cairo, etc.) In this case, we could extend Paul's new "universal_variant" variable. Instead of "yes" and "no", it could have three values. I'm not sure what they should be called yet, but: 1) an option to configure, build and install everything in one go, using -arch ppc -arch i386 (this would be default, as it is now), 2) an option to configure and build separately for each arch and install into temporary directories, then unify the result into the destroot, and 3) no universal variant at all ("none", equivalent to "no" in Paul's current code). [1] http://en.wikipedia.org/wiki/Not_Invented_Here