Re: [OE-core] [PATCH 2/2] base: Add virtual/cross-XXX recipe specific provider control handling

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

I should perhaps talk about the issues this patch series highlights.

My first observation is a conflcit between my choice of "virtual/cross-
sdk-cc" and our renaming wanting it to become "virtual/nativesdk-cross-
sdk-cc" due to MLPREFIX being needed/added for multilibs. I'm torn on
going through another iteration trying to see if "virtual/nativesdk-
cross-cc" works better, I suspect it will.

My second set of concerns are around the usability. The patch
implements DEPENDS remapping but not task[depend] handling so you end
up with changes like:

-POPULATESYSROOTDEPS:class-target = "virtual/cross-binutils:do_populate_sysroot"
+POPULATESYSROOTDEPS:class-target = "${PREFERRED_PROVIDER_virtual/cross-binutils}:do_populate_sysroot"

for the 4 cases I found where this is done in core. Not the end of the
world but will catch someone out in future (probably me).

The need to hack around the problem with allarch due to ordering issues
is a bad sign too.

I'd note that if we accepted the syntax above more widely, we could do
that everywhere and not need the remapping. It is really ugly and
unreadable though so I'm thinking that would be the wrong move.

One alternative to the second patch's approach could be "filter"
implementation for variables (Joshua once had a prototype of it) which
would help DEPENDS but not task flags.

Another would be to drop this "in metadata" approach and move the
remapping to bitbake and make it API. This was going to be my original
approach until I realised something was possible in the metadata.

Thanks for Joshua for talking through this for a minute, it has
encouraged me to write down the issues/questions.

There is unfortunately a little bit of deadline pressure too since M2
is due on Monday and I'd ideally prefer to get a change like this into
M2.

Cheers,

Richard