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

[Jérémy Rosen]

On 11/05/2016 18:02, Richard Purdie wrote:
> On Wed, 2016-05-11 at 12:15 -0300, Otavio Salvador wrote:
> 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
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
A drawback I see of intergrating it in bitbakes is... that it forces the 
user to download and install bitbake first, where bitbake is usually 
found as a subdirectory of $TOPDIR

This is also tied to the fact that yocto builds usually tag a specific 
version of the bitbake repo to use... in other word bitbake can't be the 
fetch engine because bitbake itself is a dependancy...


Repo solves this problem by being a self-contained python script (which 
also auto-updates itself, but I don't really like that feature). That's 
something to consider when designing the tool