[oe] [PATCH] base.bbclass: fix soc-family test

[Phil Blundell]

On Fri, 2010-09-10 at 15:27 -0500, Maupin, Chase wrote:
> First thanks for the response.  There a quite a few recipes that use this or plan to use it.  Kernel recipes, several of the recipes in the "recipes/ti" directory.  I guess as a person who actually uses this I have a bias here.  I hope you can understand though that this is variable found usefulness as an override and that is why it was extended to also work for COMPATIBLE_MACHINE.

I certainly don't doubt that SOC_FAMILY is useful to you and that the
code in base.bbclass serves a purpose.  There are three things, though,
that I'm not yet entirely convinced about:

a) whether SOC_FAMILY is sufficiently useful to other (i.e. non-TI)
folks to merit inclusion in base.bbclass, and is going to remain that
way; and

b) whether the high-level goals of SOC_FAMILY cannot be met in some more
generic fashion; and

c) if the answer to both (a) and (b) is yes, whether this functionality
genuinely needs to be in base.bbclass and can't be implemented somewhere
more specific.

The main reason for my uneasiness about (a) is that, although it might
appear that the concept of a "SoC family" is quite tightly defined
today, at least within the TI universe, experience suggests that the
boundaries of any given family tend to become a bit blurred over time.
Soft cores and IP blocks have a habit of being reused in new designs
which suddenly differ in some important way from the original parts for
which they were created and, unless you have a very clear definition
upfront for what constitutes the "family", you can suddenly end up with
machines which appear to be half in and half out, or which want to be
members of two families simultaneously.

As far as (b) goes, I was mostly wondering whether you could do
something with MACHINE_FEATURES.  I think I would be generally receptive
to a patch which added a variable along the general lines of
REQUIRED_MACHINE_FEATURES = "omap-core ti-rfbi ..." and which would
cause SkipPackage to be raised if all the required things didn't appear
in MACHINE_FEATURES at runtime.  Alternatively, I wonder whether you can
do some more free-form grouping of machines within the
COMPATIBLE_MACHINE syntax which doesn't involve introducing a new
variable to base.bbclass.

Finally, regarding (c), I think the question does still stand as to
whether the recipes which have SOC_FAMILY dependencies couldn't just
inherit some sort of ti-compatibility-check.bbclass which would perform
the appropriate tests.  That would allow you to do whatever you wanted
without needing to trouble base.bbclass, and you could bash it any way
you liked without needing to get code review :-)

The thing about OVERRIDES is another issue again.  Adding a new thing to
the global OVERRIDES is definitely not to be done lightly: it introduces
new namespace hazards (i.e. inadvertently triggering the override
because your MACHINE or DISTRO happens to be named the same), and it
also introduces an extra processing overhead in every parse operation.
Again, I am not keen to see this happen unless it is obvious that the
same thing can't be done better in another way.

p.