All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
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 14:39:06 +0100	[thread overview]
Message-ID: <20140127133906.GH3718@jama> (raw)
In-Reply-To: <1390829005.17424.238.camel@ted>

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2014-01-27 13:39 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 [this message]
2014-01-27 13:46                     ` Richard Purdie

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=20140127133906.GH3718@jama \
    --to=martin.jansa@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=clarson@kergoth.com \
    --cc=richard.purdie@linuxfoundation.org \
    /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.