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