merge for universal builds (was: Re: [31954] trunk/base/src/port1.0/portutil.tcl)
On Dec 12, 2007, at 11:50, mww@macports.org wrote:
Revision: 31954 http://trac.macosforge.org/projects/macports/changeset/31954 Author: mww@macports.org 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 ?
On Dec 13, 2007, at 12:23 AM, Ryan Schmidt wrote:
On Dec 12, 2007, at 11:50, mww@macports.org wrote:
Revision: 31954 http://trac.macosforge.org/projects/macports/changeset/31954 Author: mww@macports.org 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/po...
?
would you mind being a bit more specific? Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
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, mww@macports.org wrote:
Revision: 31954 http://trac.macosforge.org/projects/macports/changeset/ 31954 Author: mww@macports.org 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. 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? 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.
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, mww@macports.org wrote:
Revision: 31954 http://trac.macosforge.org/projects/macports/changeset/ 31954 Author: mww@macports.org 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/po...
?
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/
Sorry, the URL for the wiki page was missing; here it is: [1] http://trac.macports.org/projects/macports/wiki/UniversalDevelopment On Dec 14, 2007, at 2:02 PM, Markus Weissmann wrote:
...
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)
-- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
Markus Weissmann wrote:
yes. As we were running out of time in GSoC, we didn't manage to better integrate merge.rb into port(1) sooner.
Is there still work going on with merge.rb? As far as I know pipping dropped all of his ports and works now on the prefixed version of Gentoo portage. Rainer
On Dec 14, 2007, at 11:48 PM, Rainer Müller wrote:
Markus Weissmann wrote:
yes. As we were running out of time in GSoC, we didn't manage to better integrate merge.rb into port(1) sooner.
Is there still work going on with merge.rb? As far as I know pipping dropped all of his ports and works now on the prefixed version of Gentoo portage.
No, there is currently no one working on merge.rb; Elias wrote it for GSoC but currently isn't interested in universal builds. I'll integrate all of the functionality of merge.rb into port(1) so no one needs to work on it anyway. Elias joining Gentoo is perfectly o.k. for me. He has properly finished his GSoC job with us and if he is more interested in exploring portage etc. there is nothing to moan about. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
participants (3)
-
Markus Weissmann
-
Rainer Müller
-
Ryan Schmidt