Greetings all, I'm emailing about a prototype I threw together of a BBVERSIONS implementation in BitBake. This functionality is similar to BBCLASSEXTEND, but it lists versions, and sets PV rather than doing an inherit. This allows you to create one recipe that can build multiple versions of something. Either you can do one recipe that can build everything, or you could (I prefer this) create one recipe for each range of versions which are built in a given way with a given set of patches.
It helps if you think about an upstream change (which, say, breaks application of a patch) as being a change going forward. No one makes a change assuming it'll be reverted the next release, so it's likely that a given patch will apply through a set of versions, until another change breaks it further. So, metadata and patches is really rarely bound to just one version, but is instead bound to the series of versions which can be built in that way and which can have those patches applied. The version from BBVERSIONS is added to OVERRIDES, to allow for version specific metadata. In addition, you can specify a name for the range of versions, which is also added to OVERRIDES. As an example, I created a nano_1.0.0+.bb recipe which builds 1.0.0 through 1.0.6, its BBVERSIONS is set to 1.0.[0-6]. The BPV variable gets set with the 1.0.0+ value, so it can be used in the filespath, so the generic files go there, and individual versions can override further if necessary. I've been experimenting with a set of files and recipes to build every version of nano that exists, from 1.0.0 through 2.2.3, with one recipe for each set of versions. I'm still investigating to find the optimal workflow with this, someone else may want just one recipe for all versions, or they may want to leave it as is, just one recipe per version, but I suspect this may reduce the number of files duplicated across filespaths amongst versions which could be grouped together into a single recipe. Thoughts? Questions? Concerns? I've been wondering if this is really worthwhile, but I think it is. I think there is value in keeping old versions around, but this allows us to avoid cluttering up the repository as much, and makes it so that one change to a recipe can affect all the versions in that range by default, or all versions, rather than just the one version you tested. Of course, ideally you'd test all versions, but that's the case today too, its just that now our recipes get bitrotted instead. Personally, I'd rather see the old version content continue to be brought forward by default, and if it fails to build with that, we fix it, but it's easier to fix a build than to unclutter the repository. I'm hoping to get some input on this :) The bitbake changes: http://github.com/kergoth/BitBake/commits/bbversions The repository with my experimentations with nano (haven't pushed since I split the recipe by version range yet): http://gist.github.com/338382 -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
