On Dec 28, 2007, at 00:21, Boey Maun Suang wrote:

On Fri, December 14, 2007 7:42 pm, Ryan Schmidt wrote:

...

On Dec 12, 2007, at 12:52, mww@macports.org wrote:

...

+ post-patch { +# foreach arch {i386 x86_64 ppc ppc64} + foreach arch {i386 ppc} { + file copy ${worksrcpath} ${workpath}/${arch} + } + }

Perhaps we should define this list of universal architectures in MacPorts base itself, so that ports that want to do something for each arch will already have the array ready to go rather than have to define it themselves -- possibly differently from base, which would be inconsistent.

Such a definition (let's call it "universal_archs", maybe) should probably go above the definition of configure.universal_args in portconfigure.tcl. The contents of this array should be used to build up a new variable (how about "universal_arch_flags") which ends up looking like "-arch i386 -arch ppc". This string can then be used to build up configure.universal_cflags, configure.universal_cxxflags and configure.universal_ldflags.

Anyone agree? Disagree?

That looks like a reasonable suggestion to me. Given the patch that you quote, it might be better to extend the idea to handle 32- and 64-bit platforms as well, as I think that we're starting to see issues specific to single-arch 64-bit platform builds, 32-bit universal building, and so on. Still don't grok base well enough to work on this myself, though :( I'll get there one day...

mww already implemented this in base, and made the list include all 4 archs. http://trac.macports.org/projects/macports/changeset/32194 This brings up another issue though. Seems to me that all users who already have ports with the old 2-way +universal variant installed will now start seeing problems. What if, for example, I had zlib +universal installed before (and therefore have a 2-way universal of zlib installed), and now I update MacPorts base to include this 4-way universal variant, and I try to install libpng +universal, which depends on zlib, libpng will probably fail because there aren't any 64-bit versions of zlib for it to link with. We need to implement some kind of fix for this before this change in trunk can be released.