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, [EMAIL PROTECTED] 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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
