On Feb 23, 2007, at 11:36 AM, Ryan Schmidt wrote:
Now, what we could think about doing is providing some kind of default, where +universal would use the standard CFLAGS, LDFLAGS and --disable-dependency-tracking, unless the port itself defines a +universal variant. This would allow many ports to build universal. However, those for which is doesn't would then be broken. Either building with +universal would cause compilation or configuration errors, which the user could then report to the maintainer, or the software would seem to compile and build properly, but then not actually run properly on the non-native architecture. It's hard to know until you try it, separately for each software package.
I think this is a good idea. Yes, software will break, but if you make it a goal to build everything universal, it will also quickly get fixed and then you're over the hump and don't have to think about it anymore. Getting this done will also make the 32->64 bit Intel shift easier to deal with since you want to build i386/x86_64 versions universal as well (running apps as 64 bit on Core2 Duo systems is starting to become more attractive due to the extra registers you get and, of course, the larger address space). That's probably not a short-term goal, but it's somewhere on the horizon and this is one more step in the right direction.
As I said before, Apple has already gone through this for hundreds of apps and it's not as painful as many people think. A consistent build harness like MacPorts makes it even easier, since you can deal with issues like broken configure scripts (which make static determinations of endian-ness or arch) by post-processing their output before starting the build phase.
- Jordan
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-users
