Universal Binaries

Fri Feb 23 17:21:37 PST 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordan, I did not intend for it to be viewed as a optional frill, but
more an option in the sense that the "no-option choice is for the single
user" and the "optional" choice is for people with either both
architectures or developers of products for both architectures. Maybe
the /opt/local/universal is a stretch, but I meant for that path to be
reserved for the software developer/multi-architecture users. As far as
memory issues, yes, I was referring to hard drive space and not RAM
memory. Myself, I have to have an external drive to do most of the
development that I like to do because I am into a lot of geek-ary. I
make remastered wedding videos from VHS or whatever format that is
brought to me and make nice menu driven dvd videos. That takes alot of
space which leaves me having to get creative with how I manage my hard
drive space for on the go using my notebook. I have my setup like this.
Both development environments are stored on my external hard drive
(400GB) with their own partitions. When I am leaving for awhile, I have
to consider what project I will be doing the most on the go and what
projects I can not do with out. So, I sync between the partitions what I
need from both and go. I have a 60GB internal hard drive with 11GB of
free space with mostly my software development kits from subversion,
cvs, git, rsync, and whatever means available. 11GB is not a whole lot
of real estate when you are working with video and photo editing. Other
than that, I would love for universal to be default. But since that
isn't my situation, I want the option to choose.

- -Altoine

Jordan K. Hubbard wrote:
> 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:
> 
> 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
>>>>> eridius at macports.org <mailto:eridius at macports.org>
>>>>> http://www.tildesoft.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> macports-users mailing list
>>>>> macports-users at lists.macosforge.org
>>>>> <mailto:macports-users at lists.macosforge.org>
>>>>> http://lists.macosforge.org/mailman/listinfo/macports-users
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> macports-users mailing list
>>>> macports-users at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo/macports-users
_______________________________________________
macports-users mailing list
macports-users at lists.macosforge.org
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

iD8DBQFF35MgS0foIafBdlkRAmmIAJ92VaY2yYwP98xGV2jHWnwqBo2lyACgl/64
/lAwusfV0F1z77sVHSNTJrM=
=gYCu
-----END PGP SIGNATURE-----