On Tue, Jul 2, 2013 at 2:50 PM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote: > 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? >
I really think that this is something that needs to be at the individual layer level. One of the other reasons why is that, while admittedly, the yocto-autobuilder is my main concern, I can see people utilizing a lot of different autobuilders or even different yocto-autobuilder configurations. We obviously can't track those, nor should we. When things change in oe-core (or any layer) enough that an image definition disappears or changes the way we compose bblayers.conf or auto.conf, there needs to be something that I can utilize as a conditional so I can maintain backwards compatibility. I've been lucky so far in that the times these have come up I can usually peg off of LCONF_VERSION or a branch name as long as I never need to build a prior version of the branch. But that is a really lousy solution that has caused me no small amount of headache and I can see the instance coming where this is not a viable solution. I'm more than happy to hear an alternative solution though that helps not just the yocto-autobuilder but also anyone else utilizing a different CI system. > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -b -- Elizabeth Flanagan Yocto Project Build and Release _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
