[sugar] [PATCH] Refactor bundlebuilder

Jameson "Chema" Quinn jquinn
Mon May 26 09:08:59 EDT 2008

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 (http://dev.laptop.org/ticket/2892) there's a link to
my  own version of a bundlebuilder patch (
http://dev.laptop.org/git?p=users/homunq/sugar-toolkit;a=commit;h=bb ). 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:
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?


On Mon, May 26, 2008 at 2:20 AM, Wade Brainerd <wadetb at gmail.com> wrote:

> 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
> On Mon, May 26, 2008 at 1:09 AM, Morgan Collett
> <morgan.collett at gmail.com> wrote:
> > On Mon, May 26, 2008 at 1:57 AM, Marco Pesenti Gritti
> > <mpgritti at gmail.com> wrote:
> >> Hello,
> >>
> >> the attached patch refactors bundlebuilder. I'd appreciate a review
> >> before doing extensive testing.
> >>
> >> You can see the incremental changeset here:
> >> http://dev.laptop.org/git?p=users/marco/sugar-toolkit;a=summary
> >>
> >> 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
> > Sugar at lists.laptop.org
> > http://lists.laptop.org/listinfo/sugar
> >
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080526/b3cb726e/attachment.htm 

More information about the Sugar-devel mailing list