On Dec 14, 2007, at 3:18 AM, Ryan Schmidt wrote:
On Dec 12, 2007, at 18:29, Markus Weissmann wrote:
On Dec 13, 2007, at 12:23 AM, Ryan Schmidt wrote:
On Dec 12, 2007, at 11:50, [EMAIL PROTECTED] wrote:
Revision: 31954
http://trac.macosforge.org/projects/macports/changeset/
31954
Author: [EMAIL PROTECTED]
Date: 2007-12-12 09:50:49 -0800 (Wed, 12 Dec 2007)
Log Message:
-----------
add 'merge' function for mergin multiple (single arch) destroots
into one (universal) destroot
How does this compare with
http://trac.macports.org/projects/macports/browser/users/pipping/merge.rb
and how does it relate to backup() and lipo() in
http://trac.macports.org/projects/macports/browser/trunk/base/src/port1.0/portutil.tcl
?
would you mind being a bit more specific?
Does your merge() function serve the same purpose as Elias's
merge.rb script? I mean, I'm happy to see something like this in
MacPorts base, implemented in tcl, as opposed to ruby.
yes. As we were running out of time in GSoC, we didn't manage to
better integrate merge.rb into port(1) sooner.
backup() and lipo() were other functions that were added at some
point to assist in creating universal versions of ports that don't
build universal all at once. Does your merge() function obsolete
these?
no, though I want to obsolete them; I think a switch to automatically
do something like the openssl port currently does would be a good
solution. (that is, replicating all phases after 'patch' for each
involved architecture, then have 'merge' do a post-destroot
integration of the different "pre-destroots" of each arch)
Granted we need more universal support in base, but we should
coordinate things amongst ourselves, not duplicate effort, and not
create different ways of doing the same thing.
The problem is, we do not know yet how to best build the non-trivial
cases. The "merge" idea is only one piece for getting universal
support for more universal-resistant ports; others are using
emulators, different architecture build machines, etc.
If there are more people interested in working on this, we should
definitely coordinate. I've started a wiki page [1] including a list
of interested developers -- which is currently very short ;) (if this
group is getting very large, we'll get a mailing list for it)
As soon as I find some spare time, I'll add the results of our GSoC
research on how post-destroot merge works (and what is missing) and
where more investigation is necessary (e.g. emulation)
Regards,
-Markus
--
Dipl. Inf. (FH) Markus W. Weissmann
http://www.macports.org/
http://www.mweissmann.de/
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
