On Thu, 2013-06-20 at 21:33 -0300, Otavio Salvador wrote: > On Thu, Jun 20, 2013 at 7:56 PM, Flanagan, Elizabeth > <[email protected]> wrote: > > I know I've run into this issue and I'm going to bet that other folks > > have as well. > > > > When running some sort of continuous integration system (in my case, > > yocto-autobuilder), I need to build to at least two releases back. The > > problem is, sometimes, local.conf and bblayers.conf requirements > > change, for example, a layer needs a BBMASK for the prior release but > > can't have it for the current one or a layer gets split so that I need > > to add two directories to BBLAYERS as opposed to just the one that I > > used a few commits back. I currently have no great way of figuring > > that out and it has causes immense amounts of pain. > > I am sorry but I didn't follow what it will help. Can you please > provide an example? > > I always thought the right way to handle it is to have a branch...
In the autobuilder there is information about what it builds, lets say that it should build "core image-sato". Sometimes we do add/remove/rename or otherwise change things (e.g. we might drop meta-toolchain now the -c populate_sdk target works for images). What is being proposed here is that we should start using the layer version information to allow the autobuilder to have a better idea of what to run when. LAYERVERSION_core already exists for other reasons and this would seem a logical extension to it. If we're worried about the major version changes being a problem, we could use a MAJOR.minor type scheme which would still give the autobuilder the information it needs. The aitobuilder can then look at the version and run "bitbake meta-toolchain" in one case but populate_sdk for later versions, or whatever. Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
