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 [armccu...@gmail.com]
Sent: Monday, November 20, 2017 7:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] backfill mechanism
On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
<joe.sla...@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
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
