At the moment there are a couple of ways of adding components to the eSDK at build time should you wish to add some that weren't already accounted for by dependencies in the image: 1) You can add the full task name to SDK_TARGETS, e.g. in the image recipe (after the inherit!): SDK_TARGETS += "btrfs-tools-native:do_populate_sysroot" 2) Modify meta-extsdk-toolchain and add the items you want to DEPENDS (ensuring that SDK_INCLUDE_TOOLCHAIN = "1" if you are using SDK_EXT_TYPE = "minimal" Neither of these methods is particularly convenient. It should be possible to add just the native recipe name to a variable and have it work, and probably we want it to install the named items into the SDK regardless of whether SDK_EXT_TYPE is "minimal" or "full" (because the alternative behaviour in the minimal case of building things to make them available for installation after eSDK install is trivially easy, we don't need another variable for that).
I should note that this is the eSDK equivalent of the standard SDK's TOOLCHAIN_HOST_TASK (and probably TOOLCHAIN_TARGET_TASK for that matter).
I'm sure there's a good reason, but shouldn't it be possible to extend SDK and eSDK the same way?
Potentially - the issue is that the namespace is entirely different. eSDK's host part is the native sysroot, whereas the standard SDK uses a nativesdk sysroot for the same thing, so TOOLCHAIN_HOST_TASK is expressed in terms of nativesdk packages. We could certainly translate all the items in TOOLCHAIN_HOST_TASK to native recipes, I just worry that there won't always be a 1-1 match.
Still worth doing when we have the people available. -- YP bug review.