I think you're starting with a fundamental premise that Universal
binaries are something of an optional frill (and that they somehow
use more memory than non-universal ones) - neither statement is,
unfortunately, true.
First, you have to remember that even people who "build all their own
bits" are still going to run into scenarios where the bits they build
on MachineA would be useful on MachineB and they'd rather just copy a
tree over than wait multiple hours for something like KDE or xemacs
to build from scratch every single time they want it on a new machine
(and even if you only own a single machine, eventually you're going
to come up against the upgrade case where Migration Assistant will
helpfully copy all your old bits, including /opt, onto the new
machine and do you really want to run all your MacPorts stuff under
Rosetta?). Right now, the large majority of Mac users are still
using PPC machines (consider the installed base) but this balance is
tipping more and more every day as the Mac installed base actually
expands and enjoys a rate of growth far in excess of traditional PC
market growth (yay). Building universal as a DEFAULT position means
that this change is essentially painless as people switch machines,
get new machines to slide next to existing ones, and so on. Yes,
it's a fair amount of pain for us, the producers of MacPorts, but
that's just the nature of the beast - developers are accustomed to
suffering pain once so that end-users do not have to suffer it
multiple times. :-)
At Apple, we build everything universal and that includes a LOT of
open source. It's sometimes a bit of a pain to beat it into
compliance, but surprisingly not all that much pain.
Second, universal binaries do NOT use more memory than non-universal
ones. They take up a little more space on disk, but only the bits
relevant to your architecture are actually loaded into memory. What
DOES take a lot more memory is running PPC binaries under Rosetta,
which essentially needs to translate and cache the results of code
morphing on the fly.
- Jordan
On Feb 23, 2007, at 10:23 AM, Altoine Barker wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm reading up on universal binaries and such now. I see your point
but
I think it should be an option or flag that you can choose for any
particular port and not default for all ports, unless, an option to
choose to the contrary is selected to address memory space issues.
I see
a need for what you are talking about and I desire such functionality
with the idea environment, which I do not have but you do. I would
like
to sign up for such a cause, except, I am trying to get a few of my
own
projects to the point where I would then need to look at macports
providing universal binary support. I think the premise of macports is
to be self-supporting without bloat for those that seek such a
feature.
I agree for an enhanced macports that has that as an option and not
default. Since most open source code is written to be cross-platform,
there shouldn't be too many problems. Alot of work, but not too many
problems. Of course, an ability to choose the location of or a default
one created (i.e. /opt/local/universal) You wouldn't want to put it
under /System/Library/Frameworks since an update may flush your
universal ports. My $0.02.
- -Altoine
P.S. On further reading, I see it being possible. I just am not at
that
point in my goals to incorporate that task. I am more than
available to
test but I can not start or join such an endeavor until I finish a few
that I have now.
Jordan K. Hubbard wrote:
Is that one of them-there rhetorical questions? :-)
There are lots of good reasons to want universal binaries. For
one, it
allows you to NFS/AFP/... share a single /opt/local among machines
(who
says that directory always has to be local?) without having to worry
about which architecture those machines are. It also allows you to
archive up a carefully built-up /opt/local (+ /Applications/
DarwinPorts)
and give it to other people, of course.
Finally, perhaps the best reason for building universal is the
eventual
(any year now, I'm sure, and almost certainly by the next millennium)
move to releasing packaged versions of MacPorts software, complete
with
dependency tracking. You don't want to have 2 sets of packages
(assuming that only 32 bit ABIs are important) in what would
eventually
be a multi-thousand package archive.
Universal Binaries are definitely the way forward on the Mac and
porters
should be encouraged to shoot for them as the rule rather than the
exception. If disk space is a problem for any of the targets
(and it's
not that big an increase), they can always be thinned post-install
time.
- Jordan
On Feb 23, 2007, at 7:35 AM, Kevin Ballard wrote:
I'm curious as to why you want universal binaries. In general,
binaries produced via MacPorts can't be copied between platforms, as
they need all the libraries they depend on. Sure, you can copy your
entire MacPorts /opt/local tree, but outside of doing that it's
quite
hard to migrate the built products.
Given that, what benefit do you get from universal binaries?
On Feb 22, 2007, at 5:23 PM, Ryan Schmidt wrote:
On Feb 22, 2007, at 02:35, Nathan Brazil wrote:
Hi. Is it possible to produce universal binaries from MacPorts?
For example, are the GTK+ binaries produced from MacPorts specific
to the architecture of the machine it is produced on (PPC vs
Intel),
or is there a way to produce binaries that will work natively
on both?
MacPorts produces platform-native binaries. There is no way to
produce universal binaries. For many projects, it is a simple
matter
to produce universal binaries. However, some projects need to be
handled specially, so MacPorts cannot provide a guaranteed way of
automatically building universal binaries of all software. A
very few
ports provide a +universal variant.
--
Kevin Ballard
http://kevin.sb.org
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://www.tildesoft.com
_______________________________________________
macports-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.macosforge.org/mailman/listinfo/macports-users
---------------------------------------------------------------------
---
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF3zExS0foIafBdlkRAl88AKCkLDpxpoNorS5lIB03zjQXL7nfPQCdELCy
LBZWVLevtpQx3Rb7O65/aeM=
=rWsl
-----END PGP SIGNATURE-----
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
