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.