Jordan K. Hubbard
jkh at brierdr.com
Fri Feb 23 13:46:04 PST 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-users