Yocto Custom Tasks: Preserve Dependency Order When Disabling a Step

A custom validation task exists in a Yocto recipe and runs when selected explicitly, but the normal build never executes it. Later, removing an unrelated preparation task makes another step run too early. Both symptoms come from the dependency graph: registering a task, connecting it to a requested target and preserving its ordering edges are different operations.

This discussion follows BitBake 2.8. The task names are illustrative, and the proposed graph inspection does not claim that a build was executed.

Connect the task to something the build requests

The task syntax guide explains that addtask promotes a function into a task. Defining do_check_schema() and adding addtask check_schema makes it selectable, but does not necessarily put it on the default build's dependency path.

Consider addtask check_schema after do_configure. It says that when the check is needed, configuration must finish first. It does not say that compilation or the default build needs the check.

If compilation must consume only validated inputs, an illustrative connection is addtask check_schema after do_configure before do_compile. Now compile depends on the check, and the check depends on configure. The placement expresses the real prerequisite; attaching every custom task only to the end of do_build can leave an earlier consumer unprotected.

Check for other edges introduced by inherited classes before concluding that a task is unreachable. A single visible addtask line is only part of the final graph.

Deletion does not splice a chain together

Suppose a custom sequence contains prepare, normalize and consume. Consume depends on normalize, and normalize depends on prepare. Someone disables normalization by deleting its task, expecting prepare to remain before consume.

The BitBake implementation removes the deleted task from task lists and dependent-task references. It does not replace each removed edge with all of the deleted task's predecessors. Thus the route that enforced prepare-before-consume can disappear.

A serial build may conceal that defect by finishing tasks in a favorable order. Increasing parallelism exposes the missing relationship; it does not create the underlying graph error. Repair the declared dependency instead of treating a low worker count as the correctness condition.

Retain a node when only its body should stop

The task-deletion documentation recommends the noexec flag when ordering must remain intact. For the illustrative middle node, do_normalize[noexec] = "1" disables its execution while preserving its place in the dependency structure.

That is appropriate only if downstream tasks do not require outputs that normalization alone creates. Keeping an ordering barrier cannot manufacture a missing generated file. If the step is truly removed from the design, explicitly reconnect the prerequisites that the remaining consumer still needs.

Do not confuse noexec with a task being up to date. One is a metadata decision to suppress its body; the other concerns whether execution is necessary for current inputs. Forcing an up-to-date task is not a repair for a missing dependency edge.

Inspect the graph for the requested target

Use bitbake sensor-agent -c listtasks to establish whether the custom task is registered. Then use bitbake -g sensor-agent to generate the graph for the ordinary requested build, replacing the recipe name as needed.

The graph-generation reference identifies task-depends.dot as the task dependency graph and pn-buildlist as the target list. Follow the dependency route from the requested task back through the custom check. Presence in listtasks alone is insufficient.

For the deletion experiment, compare graphs before and after the metadata change. Ask whether consume still has a dependency path to prepare, rather than looking only for the disappearance of normalize. Other inherited edges may preserve the ordering, so evaluate the actual graph rather than assuming the simplified example is the whole recipe.

Finally, run the normal requested build in a suitable test configuration and inspect the relevant task execution. An explicit -c check_schema invocation proves the task can be selected; the ordinary build proves whether the intended consumer requests it.