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