linux/poky.git/bitbake/lib/bb/cache.py, branch dizzy-12.0.1

bitbake: lib/bb/*.py: Typo fixes/grammar/comment fixes, nothing functional.

2014-08-25T07:57:45+00:00

(Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953) Signed-off-by: Robert P. J. Day Signed-off-by: Richard Purdie

bitbake: codeparser cache improvements

2014-07-26T07:50:14+00:00

It turns out the codeparser cache is the bottleneck I've been observing when running bitbake commands, particularly as it grows. There are some things we can do about this: * We were processing the cache with "intern()" at save time. Its actually much more memory efficient to do this at creation time. * Use hashable objects such as frozenset rather than set so that we can compare objects * De-duplicate the cache objects, link duplicates to the same object saving memory and disk usage and improving speed * Using custom setstate/getstate to avoid the overhead of object attribute names in the cache file To make this work, a global cache was needed for the list of set objects as this was the only way I could find to get the data in at setstate object creation time :(. Parsing shows a modest improvement with these changes, cache load time is significantly better, cache save time is reduced since there is now no need to reprocess the data and cache is much smaller. We can drop the compress_keys() code and internSet code from the shared cache core since its no longer used and replaced by codeparser specific pieces. (Bitbake rev: 4aaf56bfbad4aa626be8a2f7a5f70834c3311dd3) Signed-off-by: Richard Purdie

bitbake: cache: Optimise invalid cache file handling

2014-07-26T07:50:14+00:00

If there is a corrupt/invalid cache file, we'd keep trying to reopen it. This is pointless, simplify the code paths and delete the dead file. (Bitbake rev: c22441f7025be012ad2e62a51ccb993c3a0e16c9) Signed-off-by: Richard Purdie

bitbake: cache: Don't reload the cache file since we already have this data in memory

2014-07-26T07:50:13+00:00

If we're writing out merged data to disk, its safe to assume that either we loaded the data or couldn't. Loading it again is relatively pointless and time consuming. (Bitbake rev: 14c31e18e4a4a52ee54056aeefb09ff8c295b475) Signed-off-by: Richard Purdie

bitbake: cache.py: print debug info when EXCLUDE_FROM_WORLD

2014-06-12T16:47:59+00:00

This gives us an easy way to find out which recipes have been excluded from world when there are many layers. (Bitbake rev: cf33d4bfc53ae8dc6353fa295e1acd789d4fc2d2) Signed-off-by: Robert Yang 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: cache: don't trigger reparse on recipes with wildcards in SRC_URI

2014-04-10T16:57:55+00:00

Since we now get wildcards in the file checksum list in the cache, we need to ignore them when checking to see if they still exist. This fixes connman-gnome reparsing on every bitbake execution in OE-Core. (Bitbake rev: 340c250fc664414ab2715a454bedbd19e8efe103) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: data_smart: Fix variable reference issues

2013-09-18T12:27:30+00:00

The change to use the expansion cache in VariableParse was incorrect as it was adding in references it shouldn't have been. This patch corrects the codepaths and ensures the references are correct. The cache version is bumped since the previous bug could have leave to invalid checksum calculations and a clean cache is therefore desireable. The impact of the bug was that sstate was not getting reused when it should and some tasks were also being rerun when they should not have been. (Bitbake rev: 8a42d082315bd6ce091d006bf83476db257fa48b) Signed-off-by: Richard Purdie

bitbake: runqueue: Split runqueue to use bitbake-worker

2013-06-14T11:52:56+00:00

This is a pretty fundamental change to the way bitbake operates. It splits out the task execution part of runqueue into a completely separately exec'd process called bitbake-worker. This means that the separate process has to build its own datastore and that configuration needs to be passed from the cooker over to the bitbake worker process. Known issues: * Hob is broken with this patch since it writes to the configuration and that configuration isn't preserved in bitbake-worker. * We create a worker for setscene, then a new worker for the main task execution. This is wasteful but shouldn't be hard to fix. * We probably send too much data over to bitbake-worker, need to see if we can streamline it. These are issues which will be followed up in subsequent patches. This patch sets the groundwork for the removal of the double bitbake execution for psuedo which will be in a follow on patch. (Bitbake rev: b2e26f1db28d74f2dd9df8ab4ed3b472503b9a5c) Signed-off-by: Richard Purdie

bitbake: fetch2: Fix AUTOINC handling

2013-06-14T11:52:56+00:00

AUTOINC was meant to appear once at the start of the version string. The list of names may not be sorted meaning it could get inserted in the middle. This patch simplifies the code and ensures it appears at the start. Include cache version bump to ensure the cache picks up these changes. (Bitbake rev: ad8bf10d873abb94d987860a3f6d06b134fb8a99) Signed-off-by: Richard Purdie