linux/poky.git/bitbake/lib/bb/parse/init.py, branch uninative-2.1

bitbake: bitbake: parse: fixes for resolve_file()

2018-02-14T15:26:03+00:00

The resolve_file() calls mark_dependency(), so the one which calls resolve_file() doesn't need call mark_dependency() again. (Bitbake rev: 4682571107323a39b42cd9ec8ee67419e7f15acc) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: cooker: Improve inotify overflow handling

2017-08-13T08:28:14+00:00

Add a proper function for clearing the mtime cache. Clean up the inotify event overflow case to err on the side of caution and clear any potentially now out of sync caches. (Bitbake rev: ec60459fe2ba16966544eebff43b061abb7ed3ba) Signed-off-by: Richard Purdie

bitbake: bitbake: remove True option to getVar calls

2016-11-30T15:48:09+00:00

getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?$( ?[^,()]*), True$ (Bitbake rev: 3b45c479de8640f92dd1d9f147b02e1eecfaadc8) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

bitbake: parse: Don't try to expand __base_depends/__depends

2015-11-16T11:55:07+00:00

Trying to expand a variable which isn't a string doesn't make sense. (Bitbake rev: 62367cca1f1793eb9827406bcdd5980fdeb80a60) Signed-off-by: Richard Purdie

bitbake: lib/bb/parse: properly handle OSError when updating mtime cache

2015-08-19T17:05:48+00:00

If a file no longer exists, drop it from the cache silently instead of generating a traceback. This was visible in some cases when a recipe was deleted when bitbake was resident in memory. (Bitbake rev: fe105b9042bdac4afd9f38fcf92bfdc2c04ec23f) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: bb.parse: properly error out on filesystem errors

2015-08-01T21:24:20+00:00

We've had a long-standing bug where a legitimate error reading a file (IOError or OSError) is always suppressed as though it was a 'file not found' case. As a concrete example, if you do a `chmod 000 conf/local.conf`, it'll silently not parse local.conf, rather than erroring to let the user know about the problem. Fix this by handling the ENOENT case specifically. (Bitbake rev: e691312a3add222b04e7b2f52f8df6abcb9068bf) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: bitbake: Add explict getVar param for (non) expansion

2015-06-23T10:57:53+00:00

Rather than just use d.getVar(X), use the more explict d.getVar(X, False) since at some point in the future, having the default of expansion would be nice. This is the first step towards that. This patch was mostly made using the command: sed -e 's:$getVar([^,()]*$\s*):\1, False):g' -i `grep -ril getVar *` (Bitbake rev: 659ef95c9b8aced3c4ded81c48bcc0fbde4d429f) Signed-off-by: Richard Purdie

bitbake: cooker/cache/parse: Implement pyinofity based reconfigure

2015-01-14T11:32:02+00:00

Memory resident bitbake has one current flaw, changes in the base configuration are not noticed by bitbake. The parsing cache is also refreshed on each invocation of bitbake (although the mtime cache is not cleared so its pointless). This change adds in pyinotify support and adds two different watchers, one for the base configuration and one for the parsed recipes. Changes in the latter will trigger a reparse (and an update of the mtime cache). The former will trigger a complete reload of the configuration. Note that this code will also correctly handle creation of new configuration files since the __depends and __base_depends variables already track these for cache correctness purposes. We could be a little more clever about parsing cache invalidation, right now we just invalidate the whole thing and recheck. For now, its better than what we have and doesn't seem to perform that badly though. For education and QA purposes I can document a workflow that illustrates this: $ source oe-init-build-env-memres $ time bitbake bash [base configuration is loaded, recipes are parsed, bash builds] $ time bitbake bash [command returns quickly since all caches are valid] $ touch ../meta/classes/gettext.bbclass $ time bitbake bash [reparse is triggered, time is longer than above] $ echo 'FOO = "1"' >> conf/local.conf $ time bitbake bash [reparse is triggered, but with a base configuration reload too] As far as changes go, I like this one a lot, it makes memory resident bitbake truly usable and may be the tweak we need to make it the default. The new pyinotify dependency is covered in the previous commit. (Bitbake rev: 0557d03c170fba8d7efe82be1b9641d0eb229213) Signed-off-by: Richard Purdie

bitbake: event: Add SkipRecipe event to replace SkipPackage

2014-06-01T13:29:31+00:00

In the depths of time we were rather confused about naming. bb files are recipes, the event to skip parsing them should be SkipRecipe, not SkipPackage. This changes bitbake to use the better name but leaves the other around for now. We can therefore start removing references to it from the metadata. (Bitbake rev: 98d9e6e0f514a7cb7da1d99bf4bd5602b89426d6) Signed-off-by: Richard Purdie

bitbake: parse: Improve file inheritance logging

2014-05-11T12:15:12+00:00

The file inheritance logging has been here since the dawn of time. It duplicates output many times over and logs to debug level 2. When running with the debug option, its understandable the user may want to see the paths of files included in the build. These changes remove pointless/duplicate output and print the include paths clearly at debug level one in a form which users should be able to more easily parse. (Bitbake rev: 633a56987df639295fe9128418da5634050063e5) Signed-off-by: Richard Purdie

linux/poky.git/bitbake/lib/bb/parse/__init__.py, branch uninative-2.1