11 feb 2008 kl. 22.39 skrev Ryan Schmidt:
On Feb 11, 2008, at 06:23, Emil Lundberg 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)
Thanks for revisiting this. There is a real need to be able to
compile, by default, for the native architecture of your machine.
There is also a real need to preseve backwards compatibility. A
modest proposal (based on posts and discussions old and new) that
might please everyone:
* Keep the "universal" variant for building architecture-fat
binaries (only).
* Add a new "fat" variant for building bit-fat binaries (only).
* Activate the "fat" variant by default on all library-class ports.
What are "library-class ports"? What I mean is: what criteria would
you use (what portfile variables, for example) to classify a port
as a library-class port?
A good question indeed; I was hoping you guys could answer that! :-)
I think it would need to be determined by the maintainer of the
individual port. Many ports are both applications in themselves but
also libraries (R, mysql, openssl), so the line is not so clear-cut.
My view is that _any_ port that builds shared libraries should
(ultimately) compile as bit-fat by default on 64-bit (at least on
intel, ppc folks may beg to differ). Perhaps a category ("library",
"64bit") could be added to signify this? Or a platform, but that just
sounds wrong.
But, to get things going, how about simply adding a standard variant
"64bit" that, just like "universal", is always available (right?).
The daring could then add it to variants.conf, and those who (like
myself) take an active interest in 64-bit could try ports out, file
bug reports etc. afb had a suggestion on how to handle this in a
decently port-neutral I believe.
Those on 32-bit machines, etc, would obviously not bother using it
unless they wanted to build fat binaries for some reason.
Downside is that a variant that might not be tested appears as an
option. So how is universal handled? Is it always expected to work if
it is available? Can it be disabled for the ports that for some
reason don't support it? Can one specify "-universal" for a single
port at build time?
* Add an config option to set the default bit-ness ("always 32-
bit" or "native") for all builds.
Some of it may well be in there already; I haven't been able to
locate it in the docs though, e.g. where does "universal_archs"
apply...?
I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch",
and then made them into parameters for overriding locally if
desired.
So is it possible, using the current MacPorts 1.6.0, to build bit-
fat/quad-fat binaries, and if so, how is this accomplished (feel
free to bring this onto the users-list)?
That comment applied to trunk only. 1.6.0 does not have the
universal_archs variable, and has always built only the two 32-bit
architectures. MacPorts in trunk has universal_archs, which was for
a time set to all 4 architectures, but that didn't work well and
then was changed to use only the 2 again. Someone using MacPorts
trunk could set universal_archs to a different set of architectures
to include in a universal build, but I would not expect any
portfile author to have tested with anything other than the default
"ppc i386" architecture set.
Right. I do feel, however, that architecture and bit-ness need to be
handled separately. Architechture-fat binaries, I presume, are built
to increase usability on several machines (for binary distribution in
some form), while bit-fat binaries are commonly built for use on the
_same_ machine, e.g. to provide both 32- and 64-bit version of
libraries.
I can try trunk on a demo setup, using universal_arch="ppc ppc64".
How, exactly, do I use this variable?
/Emil
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
