On Wed, 2014-12-03 at 16:16 +0800, Hongxu Jia wrote: > While archiver inherited, we edit a recipe (such > as gzip) to insert four tasks between do_patch and > do_unpack: > ... > addtask test1 after do_unpack before do_patch > addtask test2 after do_unpack before do_test1 > addtask test3 after do_test2 before do_test1 > addtask test4 after do_test2 before do_test1 > ... > > While building the recipe, the archiver will > missing these four task in do_unpack_and_patch. > Because it is hardcoded to execute do_unpach and > do_patch, did not consider the probable tasks > between them. > > We make use of the value of _task_deps which > provided by metadata to compute the probable > tasks between do_unpack and do_patch and execute > them.
_task_deps is not provided by the metadata, its a bitbake internal variable and it should not be being used in public API like this. The bitbake maintainers reserve the right to change structure and existence of _task_deps freely. So this patch *cannot* merge in this form. I do appreciate the problem you're trying to solve and that its a hard one to deal with. We should probably add some API to bb.build which allows the code to query information about tasks. I would prefer to only expose the information we need (the parents) rather than the whole contents of _task_deps since that may change over time. The main reason that structure exists at all is a performance optimisation inside the core of bitbake. Thinking about this further, have you looked at BB_TASKDEPDATA? You may well be able to extract the information you need from that and that *is* public API. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core