[OE-core] possible consequences of adding "extraneous" layers to a build?
Richard Purdie
richard.purdie at linuxfoundation.org
Sun Feb 19 17:35:10 UTC 2017
On Sat, 2017-02-18 at 13:25 -0500, Robert P. J. Day wrote:
> (currently updating a pile of my OE online pages so i'm going to
> ask
> a bunch of basic questions to make sure i'm not missing anything.)
>
> what are the basic rules for layer design such that you should
> (theoretically) be able to toss a bunch of ostensibly superfluous
> layers into a build, and it shouldn't make a difference? that is,
> leaving aside obvious conflicts in having two layers trying to define
> precisely the same thing, what are the only issues you should worry
> about in throwing more layers into your "bblayers.conf" file, even if
> you end up not using anything from them?
>
> first, it seems(?) clear that introducing new recipes or classes or
> machines or distros in those additional layers should make no
> difference -- if you weren't referring to any of those features
> before, then if you don't change your configuration, you certainly
> won't be referring to them now.
>
> the most obvious consequence is that one or more .bbappend files
> will tweak some recipes you were already building, so .bbappend files
> strike me as, really, the only consequence of note.
>
> the only thing that leaps to mind is if some really weird content
> was placed in the new layers' "layer.conf" file, but that strikes me
> as really bad design unless there's a good reason for it.
>
> so ... is there any other possible consequence of adding layers to
> a
> build that i'm overlooking?
A layer can do pretty much *anything* to the build. You can design
layers not to have an impact, or the impact may be the whole purpose of
the layer.
With YP Compatible v2, we plan to detect "invasive" changes using the
sstate checksums changing to show that the layer did something
unexpected. But in general a layer can do pretty much anything.
Cheers,
Richard
More information about the Openembedded-core
mailing list