Just say no to +universal

[Jordan K. Hubbard]

On Mar 3, 2007, at 3:16 PM, James Berry wrote:

> I am speaking about macports, not the general case. Adding huge  
> hacks to individual portfiles in order to support universal builds  
> gets us nowhere -- particularly when we don't have the distribution  
> mechanisms in place to really do anything with such universal port  
> builds.

And I hope I've made it clear that I'm not defending the "huge hacks"  
either.   I don't like huge hacks.  I like generic support that can  
be leveraged.  So far, I think the generic support for universal  
building is still pretty green, however, and I guess the ultimate  
question is whether or not MacPorts wants to invest anything in this  
area at all if people are still questioning the worth of universal  
executables and frameworks (in the context of MP) at all.   I've said  
my piece and if people still don't agree, that's cool, I just thought  
it was something worth taking a fairly strong stand over and I'm not  
going to go in the corner and cry if MP decides it's always going to  
be a "build your own stuff" solution (which still leaves a fairly big  
hole in what end-users are looking for, sadly).

> Rather than big hacks on individual ports, it would seem better to  
> have a couple of declarative statements for the universal strategy  
> of a port:
>
> 	- port may be built universal: yes/no
> 	- port builds universal out of box: yes/no
> 	- port builds in single pass with flags: xxx
> 	- port can be built in multiple passes by lipoing together the  
> following binaries... (all others are assumed the same builds)

I'm not sure what value is added by having so many states.  I think,  
as far as the builder is concerned, the only state that counts for  
anything is the first one.  Does it build universal?  Yes?  OK, then  
the builder can choose to build it universal if that's valuable to  
them.  If not, then it's a moot point.   As far as an internal  
macports developer is concerned, there's also not a lot of value in  
splitting hairs here.  If it builds universal out of the box vs  
tweaking it, that's great, but it's no different than having a port  
which compiles on MacOSX with no patches and respects $prefix  
properly in all ways vs one which has to be coerced into doing those  
things.   Whether to lipo or not depends as much on what the macports  
developer wants to do (e.g. how much trouble to go through in the  
"coercion process") as anything else, so I don't see what value a  
declarative statement adds there either.

- Jordan