On Jun 14, 2008, at 2:58 AM, Ryan Schmidt wrote: > I think we should strive not to have this situation... if the port > builds universal by default, an effort should be made to change the > build so that it builds non-universal by default, and universal only > when the universal variant is chosen. I know Anthony did this for > many ports. For my ports that build universal by default I did not do > this (sleepwatcher, and I just found out adtpro), and I should go > back and fix this.
That would, unfortunately, invert you from the default scenario for all Apple projects (and I note this only because it can cause you special headaches when linking apps that expect all their frameworks and libraries to be universal by default, some of which may be provided by MacPorts) and also the default recommended to developers. Things should build universal unless there's a really good reason for them NOT to if you want to avoid confusion and anarchy. I'm also kind of confused as to why this has been such a perennial big deal. We have hundreds of OSS projects internally at Apple which build universal and the developer community at large has largely embraced universal builds for quite some time now - there are still problems here and there, sure, but I see a definitely trend towards those getting fixed as I see more and more stuff building universal with little to no modification. I also know that there's the perceived problem of bloat (though storage is cheap and getting even cheaper) and general feelings of "why should I carry around the extra weight?", but that's short- sighted at best. People buy new machines, they migrate their old apps and files using the Migration Assistant, and this is extra insurance for this case (instead of "aww, crap, now half of my stuff doesn't work!"). As previously noted, it's also REALLY important if your port builds a library or plug-in of any kind since you just don't know the downstream impact. We have commercial software bundling in MacPorts and Fink bits all the time, as people have noted. The only real issue I see is with x86_64 and Carbon apps, but that's more of an orthogonal porting issue that we (and developers in general) are going to need to grapple with regardless once that architecture becomes the default and Carbon gets more and more nails pounded in the coffin. As to the value, and why we don't simply build everything i386/x86_64 and let the ppc folks build their own bits or upgrade their way out of trouble, there is still value to Rosetta apps having various ppc libraries available, even if 100% of your user base has gone Intel, so I think 3-way universal (ppc, i386, x86_64) is still going to be of value for a number of years. - Jordan _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev