Uh oh. I had a different version of this patch already posted in the bug, AND I was working on a newer version. Marcopg, in the bug (<a href="http://dev.laptop.org/ticket/2892">http://dev.laptop.org/ticket/2892</a>) there's a link to my  own version of a bundlebuilder patch (<a href="http://dev.laptop.org/git?p=users/homunq/sugar-toolkit;a=commit;h=bb">http://dev.laptop.org/git?p=users/homunq/sugar-toolkit;a=commit;h=bb</a> ). It's a pity you didn't start from there. Some differences: - Instead of passing around a config structure, I made essentially the whole module into a class, which kept its own config and had (almost) all the current module functions as its methods. Either way, both of us removed the dependency on working dir; the design choice here is unimportant, but removing the dependency is necessary for Develop. - I did not trim out the git_ and svn_ functions, for fear that somebody might be using them. I agree with you though, they should go (it is a dependency that sugar should not have). - I kept manifest. In my discussions at the time, I had wanted to do exactly what you have done (dump manifest for .gitignore), but some people (I think it was bemasc and m_stone, but I don't remember - it was 3 months ago) convinced me that explicit include (manifest) was the way to go. Also, this is precisely what I am working on now! Here is my proposal for a new format: <a href="http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2">http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2</a> In this format, the decision to include MANIFEST makes some things easier. An arbitrary order for MANIFEST allows a future differential-versioning datastore to deal more gracefully with file renames - the order can remain the same. And it also gives an ordering for signatures in HASHES; this could be accomplished by defining a canonical sort function, but to me it seems safer to have an explicit order. Sorry for the miscommunication - I thought that I was being noisy enough about what I am working on, but yes, I should have taken back ownership of the bug. But then again, you should have started from my patch, which is posted in the bug - or did I do that wrong? Jameson <div class="gmail_quote">On Mon, May 26, 2008 at 2:20 AM, Wade Brainerd <<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Git does a nice thing when committing where it basically says "here are the files that are not included". Printing something like this out when building .xo or .tar.bz2 files would probably help with MANIFEST omission errors, I've been bitten by that before too. Also, we have genpot, why not genmanifest?  Something like find * -t f > MANIFEST is a good place to start from. -Wade <div><div></div><div class="Wj3C7c"> On Mon, May 26, 2008 at 1:09 AM, Morgan Collett <<a href="mailto:morgan.collett@gmail.com">morgan.collett@gmail.com</a>> wrote: > On Mon, May 26, 2008 at 1:57 AM, Marco Pesenti Gritti > <<a href="mailto:mpgritti@gmail.com">mpgritti@gmail.com</a>> wrote: >> Hello, >> >> the attached patch refactors bundlebuilder. I'd appreciate a review >> before doing extensive testing. >> >> You can see the incremental changeset here: >> <a href="http://dev.laptop.org/git?p=users/marco/sugar-toolkit;a=summary" target="_blank">http://dev.laptop.org/git?p=users/marco/sugar-toolkit;a=summary</a> >> >> Other than cleanups the significant changes are: >> >> * The file inclusion logic is no more based on git/svn or a manifest >> file, instead we include all the files except well known like >> .git/.gitignore and source files like those in the po directory. This >> is unusual compared to common build systems, but it should work well >> for python bundles. The idea is that the source directory is almost >> the same of the distributed bundle. >> * dist_xo generate a xo, dist_source generate a source tarball. >> >> I'm planning to add better support for generated files using make >> (most common case being compiled C code). But I'd rather do that as a >> separate step. Also if desired we can easily allow to override the >> default file inclusion logic, or provide a choice of them (the one >> this patch implements is experimental). >> >> Marco > > Since bundle signing will need a manifest, and AFAIK Develop needs an > accurate manifest, what about autogenerating the manifest from the > files included? I have been bitten before by not updating MANIFEST > when adding files and it may become a common problem. > > Morgan > _______________________________________________ > Sugar mailing list > <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> > <a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a> > _______________________________________________ Sugar mailing list <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> <a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a> </div></div></blockquote></div>