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, [email protected] 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 > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
