Just say no to +universal

[James Berry]

On Mar 3, 2007, at 1:39 PM, Jordan K. Hubbard wrote:

>
> On Mar 3, 2007, at 12:49 PM, James Berry wrote:
>
>> I'm quite distressed by the concept of too much work (and too much  
>> ugly code) going into building +universal variants of ports.
>>
>> I'd like to see people refrain from completely bastardizing  
>> portfiles in order to support universal builds. Let's be  
>> reasonable: the case for universal builds is fringe. We don't have  
>> easy ways to transport binary ports between systems, and it's not  
>> in general a safe thing to do.
>
> I understand what you're saying with respect to "lack of easy  
> transport", but I can't agree that "the case for universal builds  
> is fringe.".  Perhaps you're talking about "fringe" purely with  
> respect to MacPorts itself, but let's zoom out for a moment and  
> look at the bigger picture again.

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.

> So, enter MacPorts.  Does MacPorts absolutely need to do this or  
> nobody will ever use it again?  Of course not.   There is, however,  
> still a lot of confusion and ignorance in the OSS community about  
> how to build things universal (particularly in the presence of  
> configure scripts, which definitely need to evolve).  A build- 
> framework like MacPorts has the ability to substantially lead the  
> way here and, by example, demonstrate to literally thousands of  
> open source developers just how to do it.   Just as importantly, by  
> grasping the nettle at the build stage, MacPorts is not setting  
> itself up for more work at the packaging stage it (I hope)  
> eventually wants to get to.   Nobody is seriously suggesting (I  
> HOPE) having parallel collections of many thousands of packages,  
> one for x86 and one for ppc (and, at some point, one full of  
> experimental 64-bit capable stuff), when it's perfectly possible  
> and encouraged to have just ONE package collection that works for  
> everything.  By not figuring out how to build universal, MacPorts  
> would merely be stealing resources from the future in order to be  
> lazy in the present.  There would be no net gain and definitely a  
> net loss as the ability to share a single /opt among multiple  
> machines on a network went out the window too.

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)

Something like that would allow us to declaratively describe what's  
needed to build many ports, and would allow macports to use several  
strategies to build universal ports:

	(1) This port can't be build universal (for whatever reason)
	(2) This port already builds universal (we don't need to do anything  
special)
	(3) This port can be built universal by setting these flags...
	(4) This port can be built as multiple versions that may then be  
lipoed together, using all binaries or those specified

We already do (2), and can mostly do (3) using a default set of  
flags. I'll argue that I'd rather see support for (4) built-in once,  
than built into each portfile.

James