Just say no to +universal

[Jordan K. Hubbard]

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.

First, universal binaries are here to stay and, once you start  
running Leopard, you will begin to look at anything which is NOT  
universal on your system with annoyance and disdain.   The reason for  
this is something I've already covered - the Macintosh community is  
becoming increasingly heterogeneous in nature as more and more Intel  
machines join the PPC installed base, and the best thing we can do  
for this community ("we" being both Apple and its associated  
developers) is make it increasingly irrelevant just which  
architecture they're using, be it PPC, PPC64, x86_32 or x86_64.   
Stuff they download off the net or run off of a CD, network or  
firewire volume should Just Work™ and work in a highly performant way  
- Rosetta is really a technology of last resort so please don't  
imagine that "ppc everywhere" is a good idea.

We're already seeing the user community put a lot of pressure on  
folks like Adobe to get their stuff universal since things like plug- 
ins and extensions make a non-Universal world really a nightmare  
(particularly when you need a PPC-only plug-in and an x86-only plug- 
in running in a web browser - you end up having to run two  
browsers).   So, bigger picture, Universal is the way to go and it's  
the message we're sending to everyone, both because it's the right  
thing to do from an advanced-technology perspective and because we  
want to present a united front on this issue to the commercial ISVs  
who might otherwise be tempted to let this one slide for awhile  
longer and continue to impact the overall Macintosh user experience  
in negative ways.

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.

I also think MacPorts will increasingly find itself to be the odd man  
out if it doesn't go down the universal road.   People ARE figuring  
out how to do it and it's become something of a badge of honor to get  
your application and frameworks building n-way universal so that your  
users don't have to think about anything more than which version of  
your product or project they want.   People who are using xcode have  
an easier time of it - they just click the universal checkbox and,  
unless they've written something egregious into their code, it just  
works.  I hope you're not saying that the Unix command-line driven  
community can't possibly build its stuff as well as xcode can since  
them's fightin' words. :-)

Now, if you're saying that the initial efforts to get there have been  
clunky and inelegant then I'm not going to dispute that since you're  
probably right.  That doesn't mean you throw the baby out with the  
bathwater, however, it means you figure out how to do a better job of  
it by learning from your early mistakes!

- Jordan