Yocto Multiconfig Dependencies: Wait for the Task That Produces the Artifact

A combined image recipe consumes an auxiliary image built under
another configuration. The build succeeds on a developer machine but
fails in a fresh workspace because the expected file is absent. A
cross-configuration dependency exists, yet it points to a task that
finishes before the artifact the consumer actually needs is ready.

The problem is a task-boundary mismatch. This article uses Yocto
Project 5.0.12 and BitBake 2.8 commit
6b443060ee96a62efb94723c97f22b51c9b20507, inspected on 19 October 2026.
Configuration and recipe names are illustrative. No multiconfig build is
claimed to have been run.

Define the
artifact before drawing the dependency

Write down what the consumer opens: a directory tree, a filesystem
image, a compressed image, a deployment file or some other output.
Include the expected configuration, machine, filename and content
identity. “Depends on the auxiliary image” is too imprecise when several
tasks contribute to that image.

Then find the producing task in the actual recipe graph. A root
filesystem directory becoming available is not the same event as a final
packaged image becoming available. Additional image creation, completion
or deployment steps can sit between them.

The multiconfig
build documentation describes mcdepends and demonstrates the
distinction between dependencies on do_rootfs and do_image. Use that
example to understand the relationship, then identify the correct task
for the real artifact instead of copying the example’s task name
unchanged.

Name both configurations
explicitly

An mcdepends entry identifies the originating configuration,
destination configuration, producer recipe and producer task. Check
those identities against the enabled configuration set. A similarly
named recipe in the default configuration is not a substitute for the
intended producer under another machine or distribution policy.

The BitBake
runqueue implementation resolves these cross-configuration
dependencies and checks that the referenced configuration and task
exist. Those checks catch important mistakes, but an existing task can
still be the wrong semantic boundary for the consumer.

For review, write the dependency in a sentence: the assembly task in
configuration main must wait for the output-producing task of recipe
auxiliary-image in configuration aux. Only then translate that sentence
into metadata. The sentence makes a reversed configuration pair or an
inappropriate task much easier to spot.

Treat
ordering and file location as separate contracts

A dependency establishes scheduling order. It does not, by itself,
tell a shell function which path to open. Record how the consumer
obtains the producer’s output location, especially when configurations
use separate temporary directories or different machine names.

Do not solve the path problem by globbing every matching filename
under a shared build tree and choosing the newest. That can select a
different configuration’s artifact or a stale output from an earlier
run. Prefer an explicit interface that identifies the intended producer
and output, with a check that the expected file is present before
consumption.

For a final image, inspect the role of the format-specific tasks and
do_image_complete. The image
task reference describes completion after image generation and
associated post-processing. Whether that boundary or a later deployment
task is appropriate depends on what the consumer requires.

Build the
failure from an empty output context

A stale file can conceal a missing dependency for months. Use a
disposable build setup with the relevant output locations initially
absent. Preserve the metadata revisions and the enabled configuration
list. The goal is to prove that the graph can produce the input, not
that the consumer can find a convenient old copy.

Record task starts and completions together with the artifact’s
creation point. If the consumer begins before the required file exists,
compare its dependency with the actual producer. If it waits correctly
but opens the wrong path, investigate the location contract rather than
adding more unrelated dependencies.

Avoid using sleeps as a repair. A delay can make one machine’s timing
appear reliable without establishing the required relationship.
Likewise, forcing a broad image rebuild can obscure the missing edge by
incidentally producing the desired file early enough.

Include
configuration mistakes in the proposed tests

A useful regression plan covers more than the successful pair:

• Reference a configuration that is not enabled and confirm that the
  configuration error is distinguishable from a missing artifact.
• Reference a nonexistent task in a disposable metadata fixture and
  preserve the resulting validation error.
• Use the correct task with an intentionally wrong consumer path to
  exercise the artifact-interface check.
• Run with no stale outputs, then with normal shared-state reuse,
  recording which producer work actually occurs.
• Change a relevant auxiliary configuration input and verify that the
  consumed artifact corresponds to the intended build.

These cases are proposed verification work. The maintenance branch
and the deployed BitBake revision should be recorded before relying on
exact diagnostics or implementation details. Do not turn the mere use of
multiconfig into a claim that duplicate work is eliminated across
configurations.

Keep the graph no
broader than necessary

Depending on a much later or unrelated target can hide the symptom,
but it makes the relationship harder to understand and can introduce
unnecessary ordering. Choose the narrowest task boundary that actually
establishes the input the consumer needs. If that boundary is unclear,
improve the producer’s artifact interface before adding more
dependencies.

Close the issue with three pieces of evidence: the producer task, the
cross-configuration edge, and the exact artifact opened by the consumer.
Together they explain why a fresh build works. Without the third piece,
a correct graph can still feed the wrong file; without the edge, a
correct path can still rely on yesterday’s output.