Just created a proper github project for my nano experimentations, and pushed the current incarnation (slightly messier than it needs to be, since I'm still experimenting with different ways of structuring it). http://github.com/kergoth/Nano-OE/tree/master/recipes/nano/.
On Mon, Mar 22, 2010 at 3:26 PM, Chris Larson <[email protected]> wrote: > 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 > -- 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
