[49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
Ryan Schmidt
ryandesign at macports.org
Thu Apr 9 05:13:45 PDT 2009
On Apr 9, 2009, at 06:24, Rainer Müller wrote:
> Ryan Schmidt wrote:
>
>> I still think rather than devote a lot of energy to this mechanism,
>> we should instead focus on building binaries, and let the server
>> merge them together -- or even let the user download both the powerpc
>> and intel binaries and have the user's macports merge them. Either
>> way, we wouldn't have to worry about figuring out how to let the
>> phases run multiple times, because the server would just run "port
>> install" multiple times instead.
>
> This sounds quite complicated. How would that work with the current
> image mode? Do merge on activate and split on deactivate?
>
> Are you planning to let the user install additional architectures time
> by time? Which would mean we need to track dependencies per
> architecture. Also we would need to ensure that no two different
> versions are merged together.
My original suggestion:
Two build servers per major OS:
Xserve G5: builds a port for ppc and again for ppc64
Xserve Xeon: builds a port for i386 and again for x86_64
Both build servers send both build products to a binaries server,
which combines all four builds into a universal build, possibly using
special instructions in the portfile for how to merge some files if
automated lipo or diff, as in muniversal, won't work.
Someone pointed out that to allow the user to select any combination
of variants, as we currently allow in macports.conf, the binaries
server would have to create many different combinations of these
(e.g. ppc+i386, i386+x86_64, ppc+ppc64+i386+x86_64, etc.). So that
would take a lot of time to create and space to store. Some of the
combinations might even be silly (e.g. ppc64+i386?).
On the other hand, my motivation for the above was so that a user who
wants, say, all 4 archs only has to download a single package instead
of 4 packages, which probably contain some amount of redundant
information. That amount would vary widely by port. Some ports might
have no shared files, or just a readme; others might have megs of
documentation or even, in the case of some games, hundreds of megs of
assets.
We could consider the idea of splitting ports with lots of shared
arch-agnostic data into a separate port, which would be marked as
arch-agnostic via a new syntax. This would cause some headaches for
each port to switch to this layout.
More information about the macports-dev
mailing list