Yocto Optional Layer Appends: Activate BBFILES_DYNAMIC by Collection Identity
An integration layer contains an append for a recipe supplied by an optional vendor layer. With the vendor layer removed, parsing reports a dangling append. Adding a hard dependency makes parsing predictable, but also makes the optional layer mandatory. BBFILES_DYNAMIC supports a more precise relationship: discover the integration files only when a named layer collection is present.
The condition is collection membership. It is not a test of whether a directory exists on disk, a recipe happens to be selected, or a package appears in an image.
Use the collection name declared by the optional layer
The BBFILES_DYNAMIC reference defines entries as a collection name followed by a filename pattern. It specifically supports optional appends without introducing a hard layer dependency.
Inspect the optional layer's BBFILE_COLLECTIONS contribution. Its identity might be vendorbase even if the repository directory is named meta-vendor-board. Use the declared identity, not a guessed directory basename.
An illustrative entry in the integration layer's layer.conf is BBFILES_DYNAMIC += "vendorbase:${LAYERDIR}/dynamic-layers/vendorbase/recipes-*/*/*.bbappend". The left side of the colon is the activation condition. The right side identifies files owned by the integration layer. It does not point at the vendor's base recipe.
Keep those optional appends outside any unconditional BBFILES pattern that also discovers them. Otherwise, removing the collection can disable the dynamic contribution while the broad ordinary pattern still exposes the same append. The resulting dangling-append error is not evidence that the condition was ignored.
Follow activation into ordinary file discovery
The examined configuration builder processes dynamic entries after reading the configured layers. When a positive collection condition matches, it appends the associated pattern to BBFILES. This is why the declaration belongs in the layer configuration, where it is available at that stage.
The file collector subsequently expands ordinary file patterns with glob matching and processes the discovered recipes and appends. A dynamic pattern does not bypass that collection machinery.
Check the directory depth against the pattern. Each wildcard component in the example corresponds to a level in the actual integration tree. Do not copy a BBMASK regular expression into this field and expect the same matching language. A valid collection condition with a pattern that matches nothing produces no useful customization.
A present collection does not guarantee a matching recipe version
The append-file rules still apply after activation. A version-specific append must correspond to the intended recipe filename. If the vendor upgrades the recipe, the collection can remain present while the old append becomes dangling.
Treat that as a separate failure. Confirm the discovered append path, then compare its basename with the available recipe. Do not weaken the collection gate or hide all dangling-append diagnostics to accommodate one outdated integration file.
A version wildcard can express an intentional broader match, but it does not establish that the append's settings remain compatible with every matching recipe. Review the interface changed by the vendor version before broadening the filename.
Verify the gate at both discovery boundaries
Use two disposable configurations: one with the optional collection enabled and one without it. In the enabled case, inspect effective BBFILE_COLLECTIONS and BBFILES, then use bitbake-layers show-appends to confirm the specific append-to-recipe relationship. Inspect one distinctive setting contributed by that append.
In the disabled case, the optional pattern should not be contributed by the positive condition, and the append must not leak in through another pattern. The integration layer should still parse without the vendor recipe.
These checks distinguish three actionable defects: the wrong collection identity, the wrong filename pattern and an activated append that no longer matches its recipe. They also keep the design honest: if non-optional integration code requires the vendor layer unconditionally, that dependency must be modeled explicitly rather than concealed behind a dynamic file gate.
