From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: Chris Larson <clarson@kergoth.com>,
bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: [PATCH] runqueue: Add output for -S option for listing the changepoints compared with an sstate cache
Date: Mon, 27 Jan 2014 13:46:58 +0000 [thread overview]
Message-ID: <1390830418.17424.248.camel@ted> (raw)
In-Reply-To: <20140127133906.GH3718@jama>
On Mon, 2014-01-27 at 14:39 +0100, Martin Jansa wrote:
> On Mon, Jan 27, 2014 at 01:23:25PM +0000, Richard Purdie wrote:
> > 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?
>
> What about using some existing parameter in combination with -S?
>
> -S + -v shows tracesigs
> -S without -v old behavior
I have some use cases locally (such as locked sigs) which could really
benefit from a string parameter which gets passed into the siggen code.
I can see us needing more than two "behaviours" of -S...
I also think using something like -v will lead to more confusion and the
code won't be particularly nice either :/.
Cheers,
Richard
prev parent reply other threads:[~2014-01-27 13:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 16:21 [PATCH] runqueue: Add output for -S option for listing the changepoints compared with an sstate cache Richard Purdie
2013-12-28 13:24 ` Martin Jansa
2013-12-30 16:18 ` Chris Larson
2013-12-30 16:25 ` [RFC][WIP][PATCH] runqueue: Don't fail without match found Martin Jansa
2013-12-30 16:29 ` [PATCH] runqueue: Add output for -S option for listing the changepoints compared with an sstate cache Chris Larson
2013-12-30 16:35 ` Martin Jansa
2013-12-30 22:10 ` Richard Purdie
2013-12-30 22:34 ` Chris Larson
2014-01-01 23:38 ` Richard Purdie
2014-01-10 14:14 ` Martin Jansa
2014-01-27 8:52 ` Martin Jansa
2014-01-21 22:37 ` Richard Purdie
2014-01-21 22:46 ` Martin Jansa
2014-01-27 13:23 ` Richard Purdie
2014-01-27 13:39 ` Martin Jansa
2014-01-27 13:46 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1390830418.17424.248.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=clarson@kergoth.com \
--cc=martin.jansa@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.