All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Chris Larson <clarson@kergoth.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: v2 [PATCH 0/2] data_smart.py: Track inclusions and assignments
Date: Tue, 22 May 2012 14:43:39 +0100	[thread overview]
Message-ID: <1337694219.8248.6.camel@ted> (raw)
In-Reply-To: <CABcZANkcJQsc2Up1umRX1ek3m+waB-Pq3cFYOCQb3A+4Uh0RNw@mail.gmail.com>

On Mon, 2012-05-21 at 12:54 -0700, Chris Larson wrote:
> On Mon, May 21, 2012 at 8:10 AM, Peter Seebach
> <peter.seebach@windriver.com> wrote:
> > This revised patch now uses Python's traceback facility to assign
> > meaningful locations (file and function, rather than line) to operations
> > which weren't specified, and correspondingly does not specify file and
> > line when the file name would have been the python code making the
> > assignment; this makes the patch smaller and the output more meaningful.
> >
> > As before, this is a patch to add tracking showing when and how variables
> > got their values, and which configuration files were included from which
> > other configuration files.
> >
> > The following changes since commit 39adb5741d9eee0879d3181be505400dffc60804:
> >  Andrei Gherzan (1):
> >        bb/fetch2/__init__.py: Don't try to compute checksums for directories
> 
> While these still aren't the prettiest, I think they're a lot cleaner
> than they were, and given the obvious value, I think we should
> consider merging them. Richard, thoughts?

I agree, I'd prefer we could find a neater way to do this but our
current structure doesn't lend itself to this and this is not looking
too bad.

My main concerns would be related to performance and since this defaults
to disabled, it shouldn't be too bad. It also does answer an important
question we do keep getting asked, namely, "how did variable X get set
or Y" or "which files did Bitbake actually look at". These changes allow
us to give people a way to answer those questions.

So I want to take a closer look through the patches but I'm leaning
toward merging them. If we find ways to make things neater, great but
this is probably as good a start as we can hope for.

Cheers,

Richard




  parent reply	other threads:[~2012-05-22 13:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 15:10 v2 [PATCH 0/2] data_smart.py: Track inclusions and assignments Peter Seebach
2012-05-21 15:10 ` [PATCH 1/2] data_smart.py: Provide (optional) logging of variable modifications Peter Seebach
2012-05-21 15:10 ` [PATCH 2/2] data_smart.py: Track configuration file inclusions Peter Seebach
2012-05-21 19:54 ` v2 [PATCH 0/2] data_smart.py: Track inclusions and assignments Chris Larson
2012-05-21 20:26   ` Peter Seebach
2012-05-22 13:43   ` Richard Purdie [this message]
2012-05-22 16:13     ` Peter Seebach
2012-05-25  6:56       ` 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=1337694219.8248.6.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=clarson@kergoth.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.