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

[Mark Hatle <mark.hatle@windriver.com>]

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.

--Mark

> 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
>