Re: [PATCH] runqueue: Add output for -S option for listing the changepoints compared with an sstate cache

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

On Tue, 2014-01-21 at 22:37 +0000, Richard Purdie wrote:
> I appreciate its taken me a while to loop back around on this but I do
> now have an idea. What I'm proposing we do is add an optional parameter
> to -S. Without any parameter it would behave as it did classically.
> 
> With a parameter, it could trigger the current "debug sstate" behaviour
> to stdout and it also allows it to trigger an sstate siggen specific
> behaviour as appripriate. I have some prototype code with writes out a
> "locked-sigs.inc" file for example, triggered from this same code block.
> 
> I think this should let us do more creative things with sstate (even
> from the OE siggen class) yet also let it remain useful for different
> people.

So we have a small potential issue here. We use python's optparse which
doesn't allow optional arguments. This means we can make -S take options
but the options must always be specified.

It has good reason for this as its near impossible for optparse to tell
the difference between:

bitbake image -S tracesigs
and
bitbake image -S image2

So our options are:

a) Require a new parameter to -S always
b) Hack it to use the option after -S as a parameter (meaning -S should
always be last on the commandline). I do have a proof of concept but it
makes me uneasy
c) Add a new option with a different name

In the interests of not doing something which binds us into a problem in
future, I'm thinking -S should start to always take a parameter. The
only issue is I'd like that parameter to be metadata (siggen) definable
so we can't validate the option passed.

Any opinions?

Cheers,

Richard