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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
