unify script in MacPorts (was: Re: Is using TclX acceptable?)

[Ryan Schmidt]

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