Uh oh.<br><br>I had a different version of this patch already posted in the bug, AND I was working on a newer version.<br><br>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:<br>
<br>- 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.<br>
<br>- 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).<br><br>- 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.<br>
<br>Also, this is precisely what I am working on now! Here is my proposal for a new format:<br><a href="http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2">http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2</a><br>
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.<br>
<br>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?<br>
<br>Jameson<br><br><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:<br><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<br>
are the files that are not included".<br>
<br>
Printing something like this out when building .xo or .tar.bz2 files<br>
would probably help with MANIFEST omission errors, I've been bitten by<br>
that before too.<br>
<br>
Also, we have genpot, why not genmanifest? Something like find * -t f<br>
> MANIFEST is a good place to start from.<br>
<font color="#888888"><br>
-Wade<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Mon, May 26, 2008 at 1:09 AM, Morgan Collett<br>
<<a href="mailto:morgan.collett@gmail.com">morgan.collett@gmail.com</a>> wrote:<br>
> On Mon, May 26, 2008 at 1:57 AM, Marco Pesenti Gritti<br>
> <<a href="mailto:mpgritti@gmail.com">mpgritti@gmail.com</a>> wrote:<br>
>> Hello,<br>
>><br>
>> the attached patch refactors bundlebuilder. I'd appreciate a review<br>
>> before doing extensive testing.<br>
>><br>
>> You can see the incremental changeset here:<br>
>> <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><br>
>><br>
>> Other than cleanups the significant changes are:<br>
>><br>
>> * The file inclusion logic is no more based on git/svn or a manifest<br>
>> file, instead we include all the files except well known like<br>
>> .git/.gitignore and source files like those in the po directory. This<br>
>> is unusual compared to common build systems, but it should work well<br>
>> for python bundles. The idea is that the source directory is almost<br>
>> the same of the distributed bundle.<br>
>> * dist_xo generate a xo, dist_source generate a source tarball.<br>
>><br>
>> I'm planning to add better support for generated files using make<br>
>> (most common case being compiled C code). But I'd rather do that as a<br>
>> separate step. Also if desired we can easily allow to override the<br>
>> default file inclusion logic, or provide a choice of them (the one<br>
>> this patch implements is experimental).<br>
>><br>
>> Marco<br>
><br>
> Since bundle signing will need a manifest, and AFAIK Develop needs an<br>
> accurate manifest, what about autogenerating the manifest from the<br>
> files included? I have been bitten before by not updating MANIFEST<br>
> when adding files and it may become a common problem.<br>
><br>
> Morgan<br>
> _______________________________________________<br>
> Sugar mailing list<br>
> <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a><br>
><br>
_______________________________________________<br>
Sugar mailing list<br>
<a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a><br>
</div></div></blockquote></div><br>