On Wed, Jun 22, 2016 at 2:56 PM, Mark Hatle <mark.hatle@windriver.com>
wrote:

> On 6/22/16 4:35 PM, Richard Purdie wrote:
> > On Wed, 2016-06-22 at 17:58 +0200, Martin Jansa wrote:
> >> On Wed, Jun 15, 2016 at 07:39:01AM +0000, git@git.openembedded.org wr
> >> ote:
> >>> rpurdie pushed a change to branch master
> >>> in repository bitbake.
> >>>
> >>>       adds  2c88afb   taskdata/runqueue: Rewrite without use of ID
> >>> indirection
> >>
> >> Is it expected that this change also changes the format of summary
> >> shown at the end of the build and failed tasks.
> >>
> >> The commit message doesn't mention this (it even says:
> >> ..
> >> On the most part there shouldn't be user visible changes.
> >> ..
> >> There should be no functionality changes in this patch, its purely a
> >> data structure change and that is visible in the patch.
> >> ..
> >> )
> >>
> >> So before I start fixing scripts (e.g. test-dependencies) which are
> >> trying to parse bitbake output to work with new format, please
> >> confirm that this was intentional and that it will stay this way.
> >>
> >> It's also not clear why the task is mentioned twice, e.g. as:
> >>   NOTE: Running task 512 of 548 (ID: /OE/build/oe-core/openembedded
> >> -core/meta/recipes-devtools/rpm/sftp.bb:do_fetch, /OE/build/oe
> >> -core/openembedded-core/meta/recipes-devtools/rpm/sftp.bb:do_fetch)
> >>   ERROR: Task /OE/build/oe-core/openembedded-core/meta/recipes
> >> -devtools/rpm/sftp.bb:do_fetch (/OE/build/oe-core/openembedded
> >> -core/meta/recipes-devtools/rpm/sftp.bb:do_fetch) failed with exit
> >> code '1'
> >>
> >> are there cases where these 2 are different? and can both messages
> >> use the same "format" for task description?
> >
> > The taskids are no more, there is simply no notion of them inside
> > bitbake any longer. That means that yes, we probably do need to change
> > the output a bit since the number doesn't mean anything.
> >
> > Equally, it shouldn't be showing the same thing twice, that is a bug.
> > Internally to bitbake, everthing is now in the form (or will be when
> > multiconfig lands) "[multiconfig:<configname>:]<recipe
> > filename>:<taskname>". The question is whether we expose that to the
> > user or massage it at all. I'm tempted just to expose that string to
> > the user.
>
> I'm certainly and advocate of just exposing that string.  I think in the
> end
> that is easier to explain to someone, then trying to understand a massaged
> output.


I'd agree with that. Using the filenames is actually a nice convenience
when you need to examine a recipe.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics