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. The code is made available under the MIT license.[3] [1] merge.rb's wiki: http://elias.binera.de/dokuwiki/doku.php [2] merge.rb's repo: http://elias.svn.binera.de/bin/cgi/viewvc.cgi/ [3] merge.rb's license: http://www.opensource.org/licenses/mit-license.php ====== Up until now I've been working on merge.rb; I think it does what it's supposed to do and it does it well. Testing is appreciated. If you've been asking yourself where those 'ppc', 'x86_64', etc. directories are supposed to come from, that's part two. merge.rb could run on a server, clients could upload their trees (built via MacPorts) to the server, etc. - the infrastructure needs to be controlled/used somehow. There are a lot of open questions and that's why I'm asking for feedback. Given merge.rb would run on a server, how would it communicate/interact with clients? Who would initiate merges or what would they be triggered by, etc. What would you want to be able to do with it? Looking forward to hearing your ideas. Kind regards, Elias Pipping _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev