[yocto] yocto beagleboard.conf -- should it not go away?

[Darren Hart]

On 09/05/2012 02:15 AM, Paul Eggleton wrote:
> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
>> The simplest fix would be for meta-ti to preppend itself to the path the
>> same way meta-yocto does, i.e., in the layer.conf
>>
>>   BBPATH := "${LAYERDIR}:${BBPATH}"
>>
>> In fact, this is the *only* way that a layer can override any conf files
>> in oe-core, which is probably what you always want in a BSP layer?
>>
>> Just quickly scanning yocto git, there are a number of BSP layers that
>> are configured the same way as meta-ti, so potentially have the same
>> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
>> layers configured this way too, but I think it's only a big issue for
>> BSP layers and distro layers.)
>>
>> As long as we are mixing layers that do both prepend and append, the
>> layering will continue to be broken in subtle and hard to identify ways.
>> I can't think of a practical use case where a layer other than oe-core
>> might need to append itself to the BBPATH? If there were no genuine need
>> for layers to append to the path, the BBPATH extension could be done
>> automatically when including the layer, instead doing manually in each
>> layer.conf, giving us some consistency.
> 
> It has been considered witin OE to be best practice to append to BBPATH and 
> not prepend, the thinking being that then the search path matches the order of 
> the layers listed in bblayers.conf rather than the reverse. I'm not sure I 
> agree with it (I tend to prefer to list OE-Core first), but that's the 
> convention adopted there.
> 
> Quite a few people have asked for the items which BBPATH controls (classes, 
> conf files) to instead be found in layer priority order. If bitbake took over 
> managing BBPATH, that would be a possibility, and as you say it would improve 
> consistency at the expense of a little flexibility.
> 
>> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
>> the BSP layer for that (and should Intel decide to add an atom-pc to 
>> meta-intel, it will be broken exactly the same as the beagleboard machine is
>> just now).
> 
> Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
> intel and then copying it back into meta-yocto, once the layer tooling allowed 
> for that to be done dynamically. Since the layer tooling is now in place that 
> is at least a practical possibility, but I'm not sure if it's still on the 
> cards - it still makes sense to me at any rate.

A case can be made, but in my opinion, atom-pc is a generic BSP (not
machine specific) and doesn't really fit with the other BSPs within
meta-intel. I believe we should have an Intel BSP in meta-yocto, but I
don't like the idea of duplicating a BSP in meta-yocto and meta-intel.
atom-pc seems like a reasonable candidate to leave in meta-yocto to me.

I could probably be convinced otherwise, but that's my current thinking.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel