unify script in MacPorts (was: Re: Is using TclX acceptable?)
ryandesign at macports.org
Sat Apr 14 21:36:50 PDT 2007
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 . 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
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).
More information about the macports-dev