SoC: current status (Elias Pipping)

Blair Zajac blair at orcaware.com
Sun Jul 22 19:31:10 PDT 2007


On Jul 22, 2007, at 9:35 AM, Elias Pipping wrote:

> Hi,
>
> here's the status:
>
> merge.rb is a tool that's designed to merge an arbitrary amount of
> single-architecture directory-trees into a single universal tree.
>
> So, given the Coreutils scenario we have four directories - ppc,  
> ppc64,
> i386, and x86_64, each holding a destroot whose architecture matches
> its name.  Here's where merge.rb comes into play. It's invoked via
>
>   merge.rb ppc ppc64 i386 x86_64,
>
> you can pass an architecture more than once (doesn't matter) or leave
> one out (does matter), pass -v or --verbose for verbose output,  
> perform
> a dryrun, change input and output directories, etc.
>
> That's all documented[1].
>
> There are also a couple of test cases, among them Coreutils, the  
> others
> include OpenSSL and LibPNG - again, all documented[1].
>
> merge.rb is written in Ruby.
>
> That's a good thing because it makes the code easy to read (even if  
> one
> does not know Ruby at all) and maintain.  The code is concise,  
> flexible
> and extensible.
>
> It's not a bad thing because it does not (need to) use MacPorts  
> internals,
> it could even be used if MacPorts was completely rewritten and none of
> its current API remained.
>
> I've set up a separate subversion repository[2] for merge.rb, from  
> time
> to time I also sync it with /users/pipping in the MacPorts repository.

Why keep it in a separate repository?  It's one more place to look  
for the code.

Regards,
Blair




More information about the macports-dev mailing list