From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Flanagan, Elizabeth" <elizabeth.flanagan@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] layer.conf: Bumping LAYERVERSION_core
Date: Tue, 02 Jul 2013 22:50:47 +0100 [thread overview]
Message-ID: <2559197.ry45lNsPXD@helios> (raw)
In-Reply-To: <CAPhnLPBiYU6CGXZV-Y8khPD593iGO5AtgHMeFRMHtf3hG8jNnw@mail.gmail.com>
Hi Beth,
On Tuesday 02 July 2013 12:20:00 Flanagan, Elizabeth wrote:
> This goes back to my RFC:
>
> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016
Sorry, I meant to reply to that email and didn't get around to it, my
apologies.
> As we are removing meta-toolchain* and replacing it with bitbake
> <imagename> -c populate_sdk this causes issues with those of us who
> need to do automated builds both on the current development branch and
> on prior development branches.
>
> Example: For prior releases, I need to build meta-toolchain*. Without
> having a simple way to figure out where this is no longer the case, I
> (and other folks who run automated builds) end up having to jump
> through a lot of hoops trying to figure out where this layer changed.
> Utilizing LAYERVERSION_* to do it makes sense as there is a
> significant change that would cause issues for build engineers. Prior
> to this I was utilizing LCONF, which was the wrong solution, but just
> happened to work in the example I'm thinking of.
I can definitely see this being useful as something you can do a conditional on
within the autobuilder code; however the original intention was that
LAYERVERSION would only get bumped on changes that would break other layers
(being that it was designed to match up with versioned layer dependencies) and
I'm not sure this is one of those changes.
This situation has come up a lot over the life of this project, and I wonder
if it's time to look at having something a bit more organised - perhaps part
of the static configuration of the autobuilder could be within the metadata,
i.e. just the values needed to specify the right version-specific behaviour?
For the purposes of the Yocto Project autobuilder we can add the needed
definitions in the meta-yocto layer rather than needing to modify OE-Core.
Could that work?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-07-02 21:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 17:45 [PATCH] layer.conf: Bumping LAYERVERSION_core Elizabeth Flanagan
2013-07-02 18:54 ` Phil Blundell
2013-07-02 19:20 ` Flanagan, Elizabeth
2013-07-02 21:50 ` Paul Eggleton [this message]
2013-07-02 22:16 ` Flanagan, Elizabeth
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=2559197.ry45lNsPXD@helios \
--to=paul.eggleton@linux.intel.com \
--cc=elizabeth.flanagan@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox