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