linux/poky.git/bitbake/lib/bb/parse, branch green-3.3.1

Implement BBVERSIONS

2010-03-25T17:25:45+00:00

This implements a feature similar to BBCLASSEXTEND, but for generating multiple versions of a given recipe. For example: BBVERSIONS = "1.0 2.0 git". In addition to the above, one can utilize [a-b] style patterns, and can have a : postfix, which allows you to essentially name the range of versions. Both the current version and the basever end up in OVERRIDES, and the basever gets placed into the BPV variable. The default BPV, if none is specified, is the original PV of the recipe, before bbversions processing. In this way, you can do things like: BBVERSIONS = "1.0.[0-6]:1.0.0+ 1.0.[7-9]:1.0.7+" SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1" Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb. (Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

Fix issues with BBCLASSEXTEND set by anonymous python, and rename some variables to improve code clarity

2010-03-22T15:03:21+00:00

(Bitbake rev: 3062e96181fe845cfd286990b0216888ddd3d228) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

Implement ??= operator

2010-03-22T15:02:59+00:00

??= is a lazy, conditional assignment. Whereas a ?= immediately assigns to the variable if the variable has not yet been set, ??= does not apply the default assignment until the end of the parse. As a result, the final ??= for a given variable is used, as opposed to the first as in ?=. Note that the initial implementation relies upon finalise() to apply the defaults, so a "bitbake -e" without specifying a recipe will not show the defaults as set by ??=. Moving application of the default into getVar adds too large a performance hit. We may want to revisit this later. (Bitbake rev: 74f50fbca194c9c72bd2a540f4b9de458cb08e2d) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

Re-getVar BBCLASSEXTEND after finalise()

2010-03-22T14:56:16+00:00

This ensures that an anonymous python function is able to manipulate the BBCLASSEXTEND contents, and, therefore, amend.inc files are able to add to it. (Bitbake rev: c7d038d404afaf4ce3735af5134163759da6f6ef) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

Error early if BBPATH is unset, rather than falling back to share/bitbake

2010-03-22T14:56:00+00:00

Better to error as early as possible rather than experience strange behavior resulting from the use of the largely useless stock bitbake.conf/base.bbclass. (Bitbake rev: 641e6cf3ec3ab4d26929cf4d2a3704ff07eed4d6) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

bitbake: [parse] In ast, make StatementGroup inherit list, and add a AstNode base class.

2010-02-15T17:07:57+00:00

(Bitbake rev: 7ea31b2842b45ffe1ca688f55207f8676442a108) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

bitbake: [parse] Use bb.which in resolve_file

2010-02-15T17:07:56+00:00

(Bitbake rev: 3cd06ed487ee0617892f154cff461379a323a1fb) Signed-off-by: Chris Larson Signed-off-by: Richard Purdie

bitbake: [parser] Make resolve_file only resolve the path

2010-02-15T17:07:55+00:00

Do not attempt to open the file in the resolve_file method (a lot like bb.which... maybe bb.which can be used). This way we don't need to open/close a file which we have already parsed. Signed-off-by: Richard Purdie

bitbake: [parser] Cache parsed .inc and .bbclass files for a parse speedup

2010-02-15T17:07:54+00:00

Have a growing dict with .inc and .bbclass'es. This avoids to reparse files we have already seen. Signed-off-by: Richard Purdie

bitbake: [parser] prepare to cache some .bbcclass and .inc files

2010-02-15T17:07:53+00:00

Our parser is shit but instead to replace it now we will see how long we can drive the wave by caching parsed files. This will not go through the feeder again but we can just reevaluate the StatementGroup. Signed-off-by: Richard Purdie