[OE-core] Bitbake output format changed Was: [oe-commits] [bitbake] branch master updated (a3f464d -> 0219271)

[Richard Purdie]

On Wed, 2016-06-22 at 17:58 +0200, Martin Jansa wrote:
> On Wed, Jun 15, 2016 at 07:39:01AM +0000, git at 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.

Sorry about the script changes, not sure we can avoid it though :( The
code is *way* easier to understand, debug and extend after these
changes FWIW so I do believe it very worth doing.

Cheers,

Richard