Ryan Schmidt wrote:
From the previous discussion, I remember that we (or rather mww)
started by changing the +universal variant to build all 4 versions (2
architectures each of 32-bit and 64-bit) but this was problematic
because many ports failed to build out of the box as 64-bit, and there
was no clear upgrade path for those who already had 2-architecture
universal variants installed, and it was said that 64-bit versions of
most ports don't make sense anyway (aren't faster, or possibly are
even slower). But it seems like we want to be able to do this for
selected ports.
Most of the ports that failed were using Carbon, or otherwise old...
(old Carbon GUI does not support 64-bit, only Cocoa GUI does that)
I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch",
and then made them into parameters for overriding locally if desired.
Suppose we say we want to define a new variant called +64bit. Let's
figure out what we want that to do. Are we asking for a way to build a
64-bit local-architecture binary instead of a 32-bit
local-architecture binary (e.g. x86_64 only)? or in addition to a
32-bit local-architecture binary by installing both into separate
paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think this is
the Mac way)? or in addition to a 32-bit local-architecture binary by
making a single fat binary (e.g. i386 and x86_64 in one file)? What if
the user selects +universal in addition to +64bit? How will we handle
that?
I have experimented with adding two new "variants" (or configure
options):
+m32
+m64
These corresponded with the GCC settings with the same name: -m32 and
-m64.
When doing +m32 it would add -m32 to CFLAGS, and thus make ppc/i386
binaries.
When saying +m64 it would instead add -m64, and make ppc64/x86_64
binaries...
The default would be "neither", meaning "go with whatever default GCC
has",
which would be 32-bit for the Apple version of gcc (Panther-Leopard at
least)
Or you can use the +universal target, and add all of them to
universal_archs.
(but this requires that the port supports building universal, at the
moment)
It probably needs a lot more thought, and needs to be separated from
configure
so that it can "build twice and merge" for ports not supporting "fat"
builds.
But for ports using GNU Autotools, the experiments did work out just
fine. :-)
While I was at it, I also added support for tweaking -march and
-mtune...
I saw some commits fly by (by afb) about the universal support in
base. Was this something to do with making the universal_archs array
configurable? If so, is that user-configurable or port-configurable?
User-configurable. Currently it is run-time, both will be config-time.
One question would be if it would affect the target platform or not ?
i.e. would the platform now be "darwin 9 i386", or "darwin 9 x86_64"
(probably it shouldn't affect the variants at all, but should affect
the binaries created so that they end up as ppc64 and x86_64 instead)
And like you mention, doing multilib on other platforms needs "lib64".
(at least I think it would, as I am not running any 64-bit just yet)
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
