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

bitbake: bitbake: cache: improve debug message

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

* Print message when cachefile is found/not can help debug. * Update "Using cache in" to "Cache dir:" since it was the same as the debug message of "codeparser & file checksum caches", which caused confusion. And whether the cache file will be used or not is still unknown at that time, so just print the cache dir. (Bitbake rev: c8d3a2016f432e8ed9e99d9c28850149ab6fd6d8) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: cache.py: fix whitespace

2017-07-18T21:39:33+00:00

(Bitbake rev: e22b1f1c0e57c6ada4fb044791159546e2260dad) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: cache: don't insert PN into PACKAGES

2017-06-28T15:02:15+00:00

The cache code currently inserts PN into the package list if it isn't already present. Whilst this ensures that the package list contains something which is important for native recipes that don't set PACKAGES, it causes confusing behaviour where a normal recipe doesn't have PN in PACKAGES: for example adding dhcp to IMAGE_INSTALL will parse successfully but fail at rootfs time as the dhcp recipe doesn't generate a dhcp package. Solve this by only adding PN to the cache's package list if the package list is empty. This results in the package list for recipes such as DHCP being correct, but native recipes continue to have just PN in the list as before. [ YOCTO #5533 ] (Bitbake rev: df31a88786ce5bd7708ff14e1379dc2a58a8c0cf) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: cache: prevent division-by-zero in load_cahefile()

2017-04-11T17:05:09+00:00

[YOCTO 11315] (Bitbake rev: 227c5acd4b40154bc61202e7bb67a13818a7d727) Signed-off-by: Markus Lehtonen Signed-off-by: Richard Purdie

bitbake: codeparser: improve handling of contains_any() and filter()

2017-04-05T22:19:17+00:00

Ensure we handle bb.utils.contains_any() as separate items, rather than how we handle contains() where every item must be in the list. Additionally, enable handling bb.utils.filter() which for the purposes of looking at dependencies is the same as contains_any(). Additionally bump the codeparser cache and recipe cache versions to invalidate the user's existing caches (ensuring that the changes take effect and avoiding "taskhash mismatch" errors respectively). (Bitbake rev: 496e3c84820a2a889d99d3604659e47a550941d5) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: bitbake: remove True option to getVarFlag calls

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

getVarFlag() now defaults to expanding by default, thus remove the True option from getVarFlag() calls with a regex search and replace. Search made with the following regex: getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\) (Bitbake rev: c19baa8c19ea8ab9b9b64fd30298d8764c6fd2cd) Signed-off-by: Joshua Lock 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: cache: allow parsing a recipe with a custom config datastore

2016-09-02T17:09:48+00:00

To accommodate the OpenEmbedded layer index recipe parsing, we have to have the ability to pass in a custom config datastore since it constructs a synthetic one. To make this possible after the multi-config changes, rename the internal _load_bbfile() function to parse_recipe(), make it a function at the module level (since it doesn't actually need to access any members of the class or instance) and move setting __BBMULTICONFIG inside it since other code will expect that to be set. Part of the fix for [YOCTO #10192]. (Bitbake rev: 5b3fedfe0822dd7effa4b6d5e96eaf42669a71df) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: bitbake: Initial multi-config support

2016-08-18T09:06:27+00:00

This patch adds the notion of supporting multiple configurations within a single build. To enable it, set a line in local.conf like: BBMULTICONFIG = "configA configB configC" This would tell bitbake that before it parses the base configuration, it should load conf/configA.conf and so on for each different configuration. These would contain lines like: MACHINE = "A" or other variables which can be set which can be built in the same build directory (or change TMPDIR not to conflict). One downside I've already discovered is that if we want to inherit this file right at the start of parsing, the only place you can put the configurations is in "cwd", since BBPATH isn't constructed until the layers are parsed and therefore using it as a preconf file isn't possible unless its located there. Execution of these targets takes the form "bitbake multiconfig:configA:core-image-minimal core-image-sato" so similar to our virtclass approach for native/nativesdk/multilib using BBCLASSEXTEND. Implementation wise, the implication is that instead of tasks being uniquely referenced with "recipename/fn:task" it now needs to be "configuration:recipename:task". We already started using "virtual" filenames for recipes when we implemented BBCLASSEXTEND and this patch adds a new prefix to these, "multiconfig::" and hence avoid changes to a large part of the codebase thanks to this. databuilder has an internal array of data stores and uses the right one depending on the supplied virtual filename. That trick allows us to use the existing parsing code including the multithreading mostly unchanged as well as most of the cache code. For recipecache, we end up with a dict of these accessed by multiconfig (mc). taskdata and runqueue can only cope with one recipecache so for taskdata, we pass in each recipecache and have it compute the result and end up with an array of taskdatas. We can only have one runqueue so there extensive changes there. This initial implementation has some drawbacks: a) There are no inter-multi-configuration dependencies as yet b) There are no sstate optimisations. This means if the build uses the same object twice in say two different TMPDIRs, it will either load from an existing sstate cache at the start or build it twice. We can then in due course look at ways in which it would only build it once and then reuse it. This will likely need significant changes to the way sstate currently works to make that possible. (Bitbake rev: 5287991691578825c847bac2368e9b51c0ede3f0) Signed-off-by: Richard Purdie

bitbake: cache: Build datastores from databuilder object

2016-08-18T09:06:26+00:00

Rather than passing in a datastore to build on top of, use the data builder object in the cache and base the parsed recipe from this. This turns things into proper objects building from one another rather than messy mixes of static and class functions. This sets things up so we can support parsing and building multiple configurations. (Bitbake rev: fef18b445c0cb6b266cd939b9c78d7cbce38663f) Signed-off-by: Richard Purdie