Yocto externalsrc: Identify Which Tasks Stop Using the Normal Source Directory
A local edit has no effect on a Yocto build, or a recipe patch suddenly seems to be missing after external-source development is enabled. Start by checking which source tree and tasks the recipe actually uses. externalsrc changes that arrangement; it does not merely add another search path for a normal fetch.
The following distinctions apply to Yocto Project 5.0.12 documentation and the examined OpenEmbedded-Core scarthgap class implementation. They help diagnose direct working-tree builds without treating them as evidence that the ordinary recipe source pipeline still works.
Confirm the selected source and build directories
The external-source build guide describes inheriting externalsrc and assigning a recipe-specific EXTERNALSRC. For an illustrative recipe called sensor-demo, a local configuration can use INHERIT += "externalsrc" and EXTERNALSRC:pn-sensor-demo = "/opt/dev/sensor-demo". Replace that example with the actual absolute working-tree path.
Read bitbake -e sensor-demo and inspect EXTERNALSRC, S, EXTERNALSRC_BUILD and B together. A valid directory on disk proves little if the override targets the wrong recipe or variant. Check the task log's compilation directory against the file you edited.
The class reference explains that the external tree becomes the source directory, while the build directory normally remains separate under the recipe work directory. EXTERNALSRC_BUILD can select another build directory, including the source tree itself when an in-tree build is necessary.
Keep those roles visible during diagnosis. A generated header in B can differ from a similarly named file in S; editing the latter does not establish which one the compiler included. Inspect the actual compile command and include order rather than copying files between the directories until the error disappears.
Understand which source preparation is bypassed
The normal recipe pipeline fetches, unpacks and patches its source before configuration. With the external tree selected, the developer supplies source that is already in the intended state. Do not expect the recipe's patch list to be reapplied automatically to that working tree.
There is an important implementation exception to the simple slogan “fetch and unpack disappear.” The scarthgap class source defaults SRCTREECOVEREDTASKS to fetch, unpack and patch tasks. It retains selected auxiliary URI types, including local files, and retains fetch/unpack when such inputs remain. Patch remains covered by the default list.
An external source recipe can therefore still need unpacked auxiliary material. Inspect the effective SRC_URI and task dependencies before removing a supposedly redundant configuration file. The presence of a fetch task does not by itself mean the main source is being downloaded instead of using EXTERNALSRC.
For a missing fix, compare the external working tree with the patch's intended change. For a missing auxiliary file, trace where unpacking places it and where the consuming task expects it. These are different failures and should not receive the same repair.
Account for mutable inputs and build-directory reuse
The examined implementation adds source-tree file checksums to compilation and uses CONFIGURE_FILES to identify configuration-sensitive files. It also prevents creation of shared-state artifacts for the external-source recipe. Check the product's exact class checkout before relying on implementation details, because the maintenance branch can receive changes.
If a change needs configuration to rerun, inspect whether the relevant file is included in that configuration tracking. A source edit and a build-system input edit can require different work. For a file excluded by the working tree's Git rules, investigate the class's tree hashing rather than assuming every filesystem change has entered the task identity.
Use separate build directories for independent target or native variants when supported. Choosing one shared in-tree build directory places generated configuration and object files alongside mutable sources; class locking is not a substitute for understanding what those generated files represent.
Finally, test the ordinary recipe after removing the external-source override in a controlled development configuration. That checks whether fetching and patching can reconstruct the intended source without the private working tree. A successful direct-tree compile answers a narrower question: the selected external files can build with the selected configuration.
