Re: BBVERSIONS

[Chris Larson <clarson@kergoth.com>]

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 <clarson@kergoth.com> 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