Re: [PRService/meta V2 1/3] meta/PRService: Added export/import fuctions.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-01-06 at 13:34 +0000, Richard Purdie wrote:
> This is good and rather inventive but I'm a little worried about the way
> we're interfacing to bitbake. I appreciate the codebase doesn't give us
> a lot of good ways to do this but we perhaps need to find better ways
> even if this means extending bitbake. I'm particularly worried that we
> need to add a new recipe and an extra task to every recipe to make this
> work.
> 
> I'm wondering if we could do something like this with an event handler:
> 
> meta/classes/primportexport.bbclass:
> """
> python primportexport_handler () {
>     if not e.data:
>         return
> 
>     if isinstance(e, bb.event.RecipeParsed):
>         [code like do_prservdump here]
> 
> }
> 
> addhandler primportexport_handler
> """
> 
> meta/conf/primpexp.conf:
> """
> INHERIT += "primportexport"
> """
> 
> and then scripts/bitbake-prserv-tool for exporting would do something
> like:
> 
> bitbake prserv-misc -c dbexport_clean 
> bitbake prserv-misc -c dbexport_metainfo
> touch meta/conf/primpexp.conf
> bitbake -p -R meta/conf/primpexp.conf
> 
> 
> You could also trigger the db_export_clean/dbexport_metainfo on
> bb.event.ParseStarted and write out the variables upon the
> bb.event.ParseCompleted event? This might mean we could end up not
> needing the prserv-misc.bb recipe at all? It would also simplify the
> script we need to run these commands and hopefully make the code
> simpler.
> 
> Also, for large amounts of python code, we're tending to place this into
> meta/lib/*.py files now since these have less parsing overhead and tend
> to lend themselves better to creation of python classes. Could you see
> if it would make sense to add a prserv.py file there containing some of
> these functions. As an example of usage, this commit is one I recently
> made doing something like this for the multlib code:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8e43f9a751f1637d483d48aa9a9a647d1e3d2003
> 
> The clear benefit in the above case comes later, in this patch where we
> can do something like:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/useradd5&id=46f5223df4e9ab6e954f1f59073793703f2ec581
> 
> but in general I think larger amounts of python code make more sense in
> lib/oe/*.py
> 
> What do you think?

Just to add, I'm not saying this has to be done this way. I think the
above likely works and will be clearer and easier to understand
(improving long term maintenance too) but if anyone can see a better
way, I'm open to ideas.

It might also be  worth adding a "force-reparse" option to bitbake so
that the "touch xxx.conf" above isn't needed.

Cheers,

Richard