Yocto Source Archives: Select Original, Patched or Configured Inputs Deliberately

A source archive contains a generated configuration header that a reviewer expected to be absent. Another archive has separate patches but no already-patched source tree. Both can be correct outputs: Yocto's archiver selects a source-processing stage, and the selected stage changes what the recipient can inspect.

Start by describing the required object. Is it the downloaded input, the code after recipe patches, or the source plus configuration results? A filename containing the product version does not answer that question.

Select a stage before comparing archive contents

Enable the class with INHERIT += "archiver" in the intended build configuration. The ARCHIVER_MODE reference defines the original, patched and configured source modes; patched is the default. For a configured-source investigation, explicitly select ARCHIVER_MODE[src] = "configured" rather than assuming that enabling the class captures everything in the build directory.

Consider a hypothetical sensor library whose recipe applies a bounds-check patch and whose configure step generates a platform header. Three concrete questions distinguish the modes:

  • Does the original input contain the upstream implementation before the recipe's patch?
  • Does the patched source contain the new bounds check, without requiring configuration output?
  • Does the configured archive also contain the generated platform choices needed for this investigation?

Choose one recognizable file or symbol for each boundary. These are proposed inspection criteria, not reports from an executed build. They make a missing file meaningful: a configuration header missing from patched mode is a different problem from a patch change missing from that same mode.

Diagram comparing original, patched and configured source archives and the independently requested companion outputs.
Original source-stage diagram. The example checks have not been executed against a build.

Original mode does not always copy one upstream tarball

The examined archiver implementation copies regular input files, but unpacks directory-backed inputs such as Git sources into newly created archives. It removes unpack destination parameters for that temporary operation. Multiple source-directory archives need unambiguous names. Patch-series files describe separate patch inputs.

Consequently, do not require every original-mode archive to have the same container bytes as an upstream download. First identify whether that input was an existing file or a directory-backed fetch result. For a Git input, inspect the archived source tree and the intended revision; for a downloaded release archive, check which existing file was copied.

A patch file beside the source is also different from its changes already being present in the source. Open the affected file before concluding that a patch is missing or has been applied twice.

Configured mode can collect an out-of-tree build directory

For ordinary recipes, the implementation reruns relevant processing in an archiver work directory. Configured mode preserves references to the original recipe sysroots. When B differs from S and exists, it copies B beneath S as build.${PF}.ar_configured before archiving. Work-shared sources and libtool-native receive special handling. Tar creation excludes selected working directories, including .pc, patches and temp.

Therefore, search the archive's member list before assuming an out-of-tree configuration result was lost. A generated header can be present below that build subdirectory rather than beside the corresponding source file.

If a custom configure function fails only during archiving, inspect its expanded paths and assumptions about WORKDIR. A hard-coded reference to the normal work tree may be incompatible with the separate archival execution. Do not repair that symptom by copying a previously generated header from an unrelated build.

Configured also does not mean portable. Generated files may describe the selected machine, toolchain or build paths. Establish whether the recipient wants to inspect those decisions or rerun configuration for another environment.

Request companion material separately

The variable reference exposes independent flags for a patch-stage diff, recipe material and environment data: ARCHIVER_MODE[diff], ARCHIVER_MODE[recipe] and ARCHIVER_MODE[dumpdata]. Selecting configured sources does not itself request all three.

The source-provisioning guide also warns against treating the entire download cache as the intended source release. It can contain unrelated or proprietary inputs.

Inspect the selected recipe's deployed archive members and companions together. If the requested object is patched code, demonstrate the actual patch change. If it is configured state, locate the generated result and explain its directory. Keep the engineering conclusion tied to that stage; the archiver setting alone does not establish legal completeness.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *