[yocto] Sysroot bug in bitbake or wrong configuration?

[Andre McCurdy]

On Tue, Sep 19, 2017 at 11:43 PM, Svein Seldal <sveinse at seldal.com> wrote:
>
> I have the spu-image.bb recipe below, and running on Pyro, the recipe
> behaves differently if the recipe is run on a fresh system with no sstate
> elements, compared to a system that has a sstate cache present.
>
> The failure is that the spu-image required the host tool "uuidgen", and thus
> has DEPENDS on "util-linux-native".

DEPENDS is basically a shorthand for saying that the
do_populate_sysroot task for the recipe(s) listed in DEPENDS should be
run before the do_configure task of the current recipe.

Since image recipes don't have a do_configure task (or at least, they
do their work in tasks such as do_rootfs which don't depend on
do_configure), using the DEPENDS shorthand for setting dependencies
for the do_configure task doesn't work.

If an image recipe's do_rootfs or do_image tasks have dependencies
then they need to be expressed using the "longhand" format, for
example:

  do_rootfs[depends] += "util-linux-native:do_populate_sysroot"

Unfortunately trying to use DEPENDS in an image recipe seems to be
quite a common mistake. Maybe we should try to make things a little
more user friendly by adding a sanity test to catch the problem? Or
perhaps do_rootfs should depend on a dummy do_configure task (and so
ensure that do_rootfs effectively sees dependencies expressed via
DEPENDS) ?

> When the -c cleanall spu-image is run
> prior to building spu-image, the recipe sysroot is properly initialized with
> util-linux-native and uuidgen is available in the task functions.
>
> If -c clean is run prior to build, or simply by deleting tmp, the sysroot
> will not be properly initialized and uuidgen is not available and the recipe
> fails
>
> Is this a bug in bitbake or am I missing something in my recipe?
>
> Best regards,
> Svein Seldal
>