[OE-core] backfill mechanism

[Slater, Joseph]

The problem is that when backfilling is done, TUNE_FEATURES, etc, all have values associated with the base arch, not the current multilib.  The "generic" solution, below, should work, although I would still use overrides when available.

Beyond what actually works, if the special backfill processing can be eliminated and regular constructs used I think that would be desirable.

Joe
________________________________________
From: Andre McCurdy [armccurdy at gmail.com]
Sent: Monday, November 20, 2017 7:24 PM
To: Slater, Joseph
Cc: openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] backfill mechanism

On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
<joe.slater at windriver.com> wrote:
> The backfill mechanism is not compatible with multilib.

Did anyone ever explain why?

> This could possibly
> be fixed, but the backfill_considered functionality is also obscure, so I
> think in at least the machine related .inc files we should replace lines
> like
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> with lines like
>
> MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"

That only works for TUNE_FEATURES which happen to have a corresponding
over-ride, so may not be a generic solution. Does something like:

  MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
'n32', 'qemu-usermode', '', d)}"

work for multilib?

> There are two advantages:  the second line works for multilib, and it is far
> more readable.
>
> Joe
>