The root cause is, I was testing the use of renameVar() from finalize, in
order to get flags copied over when an override is applied, but renameVar
removes the original, whereas the old code did not do so. Going back to the
old method, will revisit the override/flags later on.
(Bitbake rev: 2f7c498abcf675e5b8de197d8056a0581670c2bd)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This ensures the check is run for anyone using the package, including
setup.py, though it's sad that it's necessary, since all it really wants is
__version__.
Ideally, we'd avoid the version check entirely in favor of checking for
functionality, but that's rather difficult with language constructs like
context managers, so this'll do for now.
(Bitbake rev: f936f1c0edf70860ea0f39ec1a500ba43b56f289)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
See the comment in the code for details.
(Bitbake rev: 849dbd63244cbc4eaca0f1beedbb67baca024629)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This way we can fully utilize bblayers, you can do everything in bblayers.conf
and avoid setting any environment variables at all.
(Bitbake rev: 5def1c8c31432968349f9b29d6333d7962260a8b)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
types.IntType -> int
types.StringType -> basestring
...
Also moves our ImmutableTypes tuple into our own namespace.
(Bitbake rev: 83674a3a5564ecb1f9d2c9b2d5b1eeb3c31272ab)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
As an example, this displays a deprecation warning for the use of
"bb.encodeurl" when you should be using "bb.fetch.encodeurl". It includes a
convenience function for this purpose. It should be of use when moving
objects between modules permanently, changing the API the user sees.
(Bitbake rev: 78f56049ba863b2e585b89db12b32697eb879bbc)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We should add back in some proper unit testing. Doctest is rather limited,
and we haven't actually made use of it since the original implementation of
the datastore when the project started, as far as I'm aware.
(Bitbake rev: 3a11c2807972bbbddffde2fa67fc380d159da467)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This lets you do -l Default on the commandline to bump the debug level of
messages with no domain, without bumping the level of everything else.
(Bitbake rev: bef33dfc36713d8c93e38e63ddac2e4f9858e787)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Also fixes some bb.msg references from within bb.msg.
(Bitbake rev: db95af590f742c8186e84046ad9704fae1733720)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Apparently the finalise spelling is becoming less common in British English.
(Bitbake rev: 47449b2fc433e5725839ca4f7e9bca931a475838)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We should add back in some proper unit testing. Doctest is rather limited,
and we haven't actually made use of it since the original implementation of
the datastore when the project started, as far as I'm aware.
(Bitbake rev: 3a11c2807972bbbddffde2fa67fc380d159da467)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
When BBCLASSEXTEND is set, '-b' builds usually failed with messages
like
| ERROR: Parsing error data_fn virtual:native:<recipe>.bb and fn
<recipe>.bb don't match
|
| File ".../bb/providers.py", line 47, in sortPriorities
| priority = dataCache.bbfile_priority[f]
| KeyError: 'virtual:native:<recipe>.bb'
This patch fixes it and allows to specify the alternative class in a
way like
| ./bitbake -b virtual:native:<recipe>.bb
This patch was written to be so minimal as possible; variables should be
probably renamed to reflect their new meaning.
(Bitbake rev: f1c7fe9fc12161ceb3fe201cde370b929b208729)
Signed-off-by: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This is just for compatibility. We may drop it in the future, or rewrite it,
as it's not particularly pythonic.
(Bitbake rev: c4e31d7fe1d15a1e3ef2a453e7c7812d403d22cb)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Cache only uses the config metadata from the cooker, no need for the cooker itself.
(Bitbake rev: bf58d43444642d31293a341ce72292003ca5c162)
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The methodpool, ${@} expansions, anonymous python functions, event handlers
now all run with the same global context, ensuring a consistent environment
for them. Added a bb.utils.better_eval function which does an eval() with the
same globals as better_exec.
(Bitbake rev: 424d7e267b009cc19b8503eadab782736d9597d0)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
- Use a single dictionary for the context, both global & local, since for some
reason it chokes wanting a global "d" rather than a local in the metadata.
- First compile the string into a code object before running eval, so we can
include the variable name in an evaluation error.
(Bitbake rev: 49534d928a37e0804ca84eed186cd22363023b2e)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
In order to move the environment cleaning, which wants to log a
message, before cooker creation, the logging facility initialization
needs to happen earlier. So, it is now in init_logger in utils.py and
called from bitbake before the creation of the data object.
It also seems more correct to initialize a global facility like this
from a more global context than the creation of an object, of which
there could theoretically be many.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Without this patch decoding a url of this kind file://dir/filename gives
path=/filename host=dir.
With the patch it decodes as path=/dir/filename host=""
Probably nobody stumbled on this issue yet because nobody used
file:// urls with directory names in the path.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
The following utility functions were removed. Note that in this particular
case we're bypassing a proper deprecation process, as these functions are
clearly not utilized, are obvious remnants of old ways of doing things, and
some of which do not even function properly.
- tokenize
- evaluate
- flatten
- relparse
- ververify
- isjustname
- isspecific
- catpkgsplit
- pkgsplit
- pkgcmp
- dep_parenreduce
- dep_opconvert
(Bitbake rev: 62983ad9b151ee8d51e8cf9a31c736c7813edf16)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
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
:<basever> 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 <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
When not expanding PREMIRRORS, the functions fails/does not work correctly
when PREMIRRORS is not a plain string (e.g. contains ${...} or a ${@...}
statements).
(Bitbake rev: d612d22b073f68b8cf1bb7344e0487820040d80d)
Signed-off-by: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
(Bitbake rev: b2486ec57c6a7adf09d0960fdf6727881b324d2f)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This prevents a misleading backtrace:
ERROR: no files to build.
Command execution failed: Traceback (most recent call last):
File ".../bitbake/build/lib/bb/command.py", line 83, in runAsyncCommand
self.cooker.updateCache()
File ".../bitbake/build/lib/bb/cooker.py", line 779, in updateCache
if not self.parser.parse_next():
File ".../bitbake/build/lib/bb/cooker.py", line 969, in parse_next
cooker.bb_cache.sync()
UnboundLocalError: local variable 'cooker' referenced before assignment
(Bitbake rev: 060ef3d957615b7eb1209dc0d01ebeb53f8c4edc)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
??= 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 <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
dict objects provide an __iter__ method for the iteration which gives you the
keys, so calling keys directly is unnecessary, and isn't really a best
practice. The only time you really need to call the keys is if there's a
danger of the dict changing out from underneith you, either due to external
forces or due to modification of the iterable in the loop. Iterations over
os.environ are apparently subject to such changes, so they must continue to
use keys().
As an aside, also switches a couple spots to using sorted() rather than
creating a temporary list with keys() and sorting that.
(Bitbake rev: 5b6ccb16c6e71e23dac6920cd2df994d67c2587b)
Signed-off-by: Chris Larson <clarson@mvista.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
..to make copy and paste of the logfile easier.
(Bitbake rev: 446cc0cebd4daff7f849717f4cb89ac1b4c6b755)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
(Bitbake rev: f68406e864c9837feb56cbec993b620481445cc2)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
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 <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
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 <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The Git fetcher currently hardwires the git command to "git". Allow the
path and any additional wrappers to the Git command to be provided via
FETCHCMD functionality, as with some of the other fetchers.
If FETCHCMD_git is not define in bitbake.conf, the fetcher defaults to "git".
(Bitbake rev: f3afb79ecac30d973a3c62ff6baf28d8b7388a24)
Signed-off-by: Malcolm Crossley <malcolm.crossley@ge.com>
Signed-off-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Chris Larson
Bernhard Reutner-Fischer
Khem Raj
Chris Larson
Enrico Scholz
Richard Purdie
Jeff Dike
Joshua Lock
Nitin A Kamble
Chris Larson
Tom Rini
Martyn Welch