Re: [OE-core] [PATCH] archiver.bbclass: Fix archiver interaction with kernel recipes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2024-10-10 at 13:25 +0800, Phil Reid via lists.openembedded.org
wrote:
> Changes to the logic of is_work_shared where made in
> commit: 5fbb4ca8da4f4f1ea426275c45634802dcb5a575
> "archiver.bbclass: Improve work-shared checking"
> 
> The resuled in a change of the logic (simplifed here) from:
>   inherits(gcc-source) or inherits(kernel) or (inherits(kernelsrc)
> and srcin(work-shared))
> to just
>   srcin(work-shared)
> 
> With INHERIT += "archiver" in the local.conf and a kernel recipe that
> uses
> KERNEL_PACKAGE_NAME. When KERNEL_PACKAGE_NAME is defined the kernel
> source is not placed into work-shared, but the archiver ends up
> deleting the source folder in the work dir, and the build
> subsequently fails.
> 
> Restore the previous logic while also mainting the referenced commits
> intent
> to consider all recipes that use work-shared. Logic is now
>   inherits(gcc-source) or inherits(kernel) or srcin(work-shared)
> 
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
>  meta/classes/archiver.bbclass | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

You're effectively reverting that commit whilst changing the logic so
it looks slightly different.

Was there a problem with gcc-source archiving as I notice the patch
adds gcc-source back too?

The commit message isn't quite accurate as gcc-source isn't something
which gets inherited.

Does this only happen with kernel recipes which use
KERNEL_PACKAGE_NAME? That might be the key missing detail which would
allow us to reproduce the failure.

Cheers,

Richard