From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>,
OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: possible consequences of adding "extraneous" layers to a build?
Date: Sun, 19 Feb 2017 09:35:10 -0800 [thread overview]
Message-ID: <1487525710.30548.20.camel@linuxfoundation.org> (raw)
In-Reply-To: <alpine.LFD.2.20.1702181316120.26007@localhost.localdomain>
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
next prev parent reply other threads:[~2017-02-19 17:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-18 18:25 possible consequences of adding "extraneous" layers to a build? Robert P. J. Day
2017-02-19 17:35 ` Richard Purdie [this message]
2017-02-19 18:19 ` Robert P. J. Day
2017-02-20 10:08 ` Andre McCurdy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1487525710.30548.20.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=rpjday@crashcourse.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.