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

[Richard Purdie]

On Wed, 2016-05-11 at 12:15 -0300, Otavio Salvador wrote:
> On Wed, May 11, 2016 at 11:44 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > 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:
> ...
> > > 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.
> 
> I know English is not my native language but I think I wrote:
> 
>  "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."
> 
> What I meant is both companies have public repositories which address
> this problem and we can learn from them. Instead of throw a stone on
> me, did you read the doc and checked what it can do?

Otavio and I did talk a little off list. I did respond fairly strongly
to his email, perhaps too much so. The bit which triggered that was "I
think adding a setup logic on BitBake violates the KISS principle. It
does not belongs there and ought to be done externally.". That
basically kills my proposal dead but I should explain why as perhaps
that isn't clear.

If we go down the external tool route, firstly that doesn't change
things much from the way things are today. There is nothing stopping
people creating external tools now, or in the future. These obviously
have features and drawbacks but a clear winning standard is yet to
emerge. 5 years on since the Yocto Project came into being and we
started pushing the layer model, I personally think one would have by
now if it was going to.

The alternative to that model is to pick and promote a tool. One way to
do that is to put it into bitbake. This helps encourage
standardisation, since people then are encouraged to change and focus
on one rather than just doing their own thing.

Putting something into bitbake (as a separate tool) has some other
advantages, in that if bitbake is present, we get its parser and its
fetcher code "for free". Being a separate tool means we don't need to
complicate bitbake itself more, means the tool can easily be replaced
by those who don't like it and it can have its own commandline struture
(bitbake itself is very difficult to extend at the commandline level).

As with anything we do in OE, we're not going to force everyone down a
particular route, differentiation is good and great things can come
from it. We'd have to make any alternative in the core good enough that
people can't afford not to switch.

Cheers,

Richard