[Openembedded-architecture] bblayers.conf - Past, Present and Future?

[Nicolas Dechesne]

On Wed, May 11, 2016 at 4:08 PM, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
> Hello Richard,
>
> On Wed, May 11, 2016 at 8:42 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> We currently have a few different ways people setup and build
>> combinations of OE layers. Koen's presentation and ELC covers some of
>> this, we've also heard representations at OEDEM/OEDAM and I think
>> everyone would agree that its worth seeing if there is some way we
>> could improve the situation.
>>
>> We have various tools/options:
>>
>> * TEMPLATECONF
>> * combo-layer
>> * repo
>> * git submodules
>>
>> and we all have views, some of them quite strong about different
>> elements of these.
>
> I am on the repo 'camp'.

me too. and that's what we decided to settle on for all Linaro builds too.

repo is ok as a tool to fetch. the only limitation is that it fetches
only 'git', but I suspect this should be enough for OE layers..

there is one very handy command with repo... 'repo grep', given the
nature of our environment and layers the ability to grep all layers at
once is priceless. You can do that with combined repos (combo-layer)
like poky, but whatever we end up doing we must provide this ability.

>
> Back in 2011 when we were creating the FSL Community BSP structure, we
> were using combo-layer internally at O.S. Systems and we tested git
> submodules and repo. We ended opting to go with repo and it turns to
> be an easy to use setup. However, fetching the repositories is just
> part of the problem...

exactly. the main issues are related to setting up bblayers.conf and
other conf files. this is where we've all invented our own tools..

>
> ...
>> In parallel, we're seeing people trying to use OE in CI systems. To
>> make buildbot work for the Yocto Project, we have a ton of
>> configuration and "fetching" code and I know Jenkins integration runs
>> into the same issues. We'd love to be able to throw away the need to
>> have CI specific layer addition code, or the bulk of the custom git
>> fetcher we ended up having to add there for example.
>
> We have a script which hides most of this for us. The OSYIS[1] help us
> to hide this.
>
> 1. http://code.ossystems.com.br/gitweb?p=osyis.git
>
> For Jenkins we just fetch the code (which it has nice plugins for
> repo) and use the OSYIS to setup the build for us. It has support for
> modules which allow for custom handles to be written when need.
>
> I think adding a setup logic on BitBake violates the KISS principle.
> It does not belongs there and ought to be done externally. We have
> developed the ossystems-yocto-base-scripts[2][3] which leverages the
> initial setup-environment idea implemented in the FSL Community BSP
> and enables the use of Python hooks for layers.

I tend to agree that this seems to be out of the scope of bitbake, but
in the scope of the OpenEmbedded project. we need tools to address
1) fetch the right set of layers (and keep them up to date, and switch
between branches)
2) setup of the 'build' environment and its conf files


>
> 2. http://code.ossystems.com.br/gitweb?p=ossystems-yocto-base-scripts.git
> 3. http://doc.ossystems.com.br/managing-platforms.html

I didn't know about this specific base-scripts. I will look more into
it. We use something similar..

>
> Some ideas were inspired on Mentor Graphics scripts, while others were
> designed by us.
>
> I think a mix of our tools, with the Mentor Graphics ones, would
> provide a good basis for it. This is something Christopher and I been
> discussing for some time but did not yet started to work on.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture