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

[Richard Purdie]

On Wed, 2016-05-11 at 11:08 -0300, Otavio Salvador wrote:
> On Wed, May 11, 2016 at 8:42 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> ...
> > 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.

Keep in mind that its exactly for that reason I don't want to have
bitbake itself actually fetching layers and I'm proposing a separate
tool.

I am proposing it be in the bitbake repository so that its easily
available and encourages some kind of standardisation.

Right now, everyone does this differently and we have the same problem
YP was trying to set out and solve in a different area, "Multiple ways
of doing kind of the same thing, differently, each with advantages but
also with some disadvantages".

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

Its easy to say "hey, everyone should copy what I do". Creating
something common/extensible which people can base off and around would
be very in keeping with what the project tries to do so I think its
worth asking questions to see if its possible.

If everyone just wants to reply "mine is best" and that we don't want
to bother even trying, so be it though. I've way too much to do already
so perhaps this is best ignored.

Cheers,

Richard