[meta-ti] [PATCH 1/3] matrix-gui-browser: port from arago overlay

[Koen Kooi]

Op 27 jan. 2012, om 22:52 heeft William Mills het volgende geschreven:

> 
> 
> On 01/27/2012 03:55 PM, Maupin, Chase wrote:
>>> Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende
>>> geschreven:
>>>> On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote:
>>>> How about splitting meta-ti into:
>>>> * BSP only
>>>> * SGX graphics
>>>> * DSP tools
>>> Since sgx and dsp are built into the SoC, why isn't it considered
>>> BSP? I must really start warming about getting overzealous with
>>> layers and breeding a silo mentality. I'm not saying we only need
>>> one layer, but not a gazillion like the base proposal.
>> I did not read the above as making a bunch of layers in meta-ti.  At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices.
>> 
> 
> Well that was the proposal and why I figured you would barf all over it.  I am OK with all the above in one layer (but separate dirs) if it all works with all the layer stack combinations we are targeting.  The issue is we have no meta-ti+oe-core builds going on so we don't know where the dependencies will be hard to break.
> 
> We all know the DSP support can get involved.  If we got to the point where BSP and graphics worked with oe-core but DSP support needed meta-oe or something else, then I would want the DSP stuff in a separate layer so people that did not need it could opt out.
> 
> Likewise people using TI WIFI on non-TI processors should be able to get that in any layer stack.  If that all works with all the above in one layer thats fine.  We just don't know yet.  We can be optimistic and put it all in one layer or pessamistic and seperate them.  In this example I am more inclined to believe that the other TI stuff would not cause problems.
> 
> Koen:  having a number of layers in on repo is a bad thing?  You should tell the meta-oe maintainer because that guys has a good number of layers in there.  :)  Are you saying that was the wrong thing to do for meta-oe?  Is there a leason learned?

It's getting late here, so I'll give the short version: every additional layer is a pain to maintain and it's even worse for the type of users we target. You need a really good set of layer tools, which still don't exist :(
And I just know that someone is going to ask the "why do I need 5 TI layers for my simple board?" question and I don't think we can give a satisfactory answer for users based on this discussion.

So what about this plan:

1) evaluate directory structure of the current meta-ti, fix if needed
2) break the easy dependencies on external layers by duplicating the image recipes.
3) document the remaining dependencies in the README

That should get us a layer that parses when being using with only bitbake+oe-core. Kernel and u-boot will build & work with the right toolchain

4) rename our u-boot recipes per the earlier RFC

That should avoid clashes with other layers

The remaining tasks are a bit more involved:

5) make our kernel+bootloaders compile and work with gcc 4.6/binutils 2.22
6) Make SOC_FAMILY work or find an equivalent

regards,

Koen