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

[Anders Darander]

* Jérémy Rosen <jeremy.rosen at smile.fr> [160512 09:41]:
> On 11/05/2016 18:02, Richard Purdie wrote:
> > 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...

Yes, this is also a concern of my.

Say that I've got a few different release branches, all based on
different OE / YP releases. Would I need to checkout different bitbakes
in order to setup my builds? If so, that means that we'd likely have to
use one bitbake to setup the build, and as a part of that, checkout
another bitbake to use for the buid...

This is at least something that we have to consider.


> 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

Yes, this is definitely something that has to be considered. 

I'm personally in the minority that solves this by fetching all external
layers (including oe-core and bitbake) as submodules of the project
repo). Not that I'm advocating that approach, as most people dislikes
the submodules... ;)

Cheers,
Anders
-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB