merge for universal builds (was: Re: [31954]
trunk/base/src/port1.0/portutil.tcl)
Markus Weissmann
mww at macports.org
Fri Dec 14 05:02:49 PST 2007
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 at macports.org wrote:
>>>
>>>> Revision: 31954
>>>> http://trac.macosforge.org/projects/macports/changeset/
>>>> 31954
>>>> Author: mww at 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.
>
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/
More information about the macports-dev
mailing list