linux/poky.git/bitbake/lib/bb/parse/parse_py/BBHandler.py, branch 1.6_M5

bitbake: ast/BBHandler/build: Add support for removing tasks (deltask)

2013-12-18T17:08:07+00:00

Back in the depths of time we did support task removal. In the pre AST days it was nearly impossible to continue supporting it, it wasn't used so it was dropped. With the modern codebase we can easily now support deltask and it would be very useful within the metadata since it can massively simplify dependency trees. As an example, a core-image-sato had 47703 inter task dependencies before this patch and a patch to native.bbclass, afterwards with the noexec tasks deleted, we had 29883. Such a significant simplification is worthwhile and justifies adding a deltask operation to the system. (Bitbake rev: acecbde6fb70ff3c96deab3cdf819d8442e87ed4) Signed-off-by: Richard Purdie

bitbake: parse/ConfHander/BBHandler/utils: Fix cache dependency bugs

2013-11-30T22:26:30+00:00

Currently bitbake only adds files to its dependency list if they exist. If you add 'include foo.inc' to your recipe and the file doesn't exist, then later you add the file, the cache will not be invalidated. This leads to another bug which is that if files don't exist and then you add them and they should be found first due to BBPATH, again the cache won't invalidate. This patch adds in tracking of files we check for the existence of so that if they are added later, the cache correctly invalidates. This necessitated a new version of bb.utils.which which returns a list of files tested for. The patch also adds in checks for duplicate file includes and for now prints a warning about this. That will likely become a fatal error at some point since its never usually desired to include a file twice. The same issue is also fixed for class inheritance. Now when a class is added which would be found in the usual search path, it will cause the cache to be invalidated. Unfortunately this is old code in bitbake and the patch isn't the neatest since we have to work within that framework. [YOCTO #5611] [YOCTO #4425] (Bitbake rev: 78d285871e4b8c54ccc4602d571e85f922e37ccd) Signed-off-by: Richard Purdie

bitbake: methodpool: Retire it, remove global method scope

2013-05-24T09:34:52+00:00

Having a global method scope confuses users and with the introduction of parallel parsing, its not even possible to correctly detect conflicting functions. Rather than try and fix that, its simpler to retire the global method scope and restrict functions to those locations they're defined within. This is more what users actually expect too. If we remove the global function scope, the need for methodpool is reduced to the point we may as well retire it. There is some small loss of caching of parsed functions but timing measurements so the impact to be neglibile in the overall parsing time. (Bitbake rev: 4d50690489ee8dc329a9b0c7bc4ceb29b71e95e9) Signed-off-by: Richard Purdie

bitbake: lib: Clean up various file access syntax

2013-05-09T21:28:04+00:00

Python 3 is stricter about how files are accessed. Specficially: * Use open(), not file() * Use binary mode for binary files (when checksumming) * Use with statements to ensure files get closed * Add missing file close statements (Bitbake rev: 9f08b901375ba640f47596f1bcf43f98a931550f) Signed-off-by: Richard Purdie

bitbake: BBHandler/ConfHandler: Merge fix for multiline comments

2013-01-21T11:01:53+00:00

This was meant to be squashed into the previous commit for multiline comment handling. It fixes the case the commented multiline is followed by an empty line which was resulting in a traceback instead of a sane error message. (Bitbake rev: 7e7d692e244fe8dca533f842ca143b9c821e317c) Signed-off-by: Richard Purdie

bitbake: bitbake: BBHandler/ConfHandler: Improve multiline comment handling

2013-01-21T10:55:45+00:00

Faced with an expression like: # Some comment \ FOO = "bar" what should bitbake do? Technically, the \ character means its multiline and currently the code treats this as a continuation of the comment. This can surprise some people and is not intuitive. This patch makes bitbake simply error and asks the user to be clearer about what they mean. (Bitbake rev: 589d31ce41e019ee6a7cb6527d67bc76c0b6382a) (Bitbake rev: 79c00fabe08b4c210a3bd81cfaffbc47ffdc2e2b) Signed-off-by: Richard Purdie

bitbake: BBHandler/data: Standardise some setVar access formats

2013-01-18T12:35:18+00:00

(Bitbake rev: e12c1a485f96a4701144ac81179ae1af348e5bf3) Signed-off-by: Richard Purdie

bitbake: data_smart/BBHandler: Fix SkipParse exception handling

2012-12-14T12:36:04+00:00

If SkipParse is raised from something which isn't anonymous python, it wasn't being handled correctly. This improves the handling for example from within inline python. (Bitbake rev: 7467d7d66b24cc8f43ab168e65895e7c4aee6092) Signed-off-by: Richard Purdie

bitbake: BBhandler/data: Fix __inherit_cache duplication

2012-12-11T15:59:42+00:00

The inherits cache contains duplicate entries, some with the full patch, some just starting classes/xxx. This is a waste of parse time and potentially error prone. This patch fixes various pieces of code so the absolute paths are always preferred and work correctly. The inherits_class function did not work with full paths so the patch fixes this. (Bitbake rev: f3a71e509af196391ec126d079cf1bd178e62ad5) Signed-off-by: Richard Purdie

bitbake: BBHandler/ast: Simplify/fix EXPORT_FUNCTIONS usage

2012-12-11T15:59:42+00:00

The current usage of EXPORT_FUNCTIONS is rather problematic since a class list (classes) is passed into the ast statement and cached as it was when first parsed. This class list may be different in other cases but is locked once in the cache. Worse, the construction of classes can be broken by exceptions during parsing at the wrong moments since the state of the parser is not always reset correctly. This can lead to leakage of other classes into the classes list. The current EXPORT_FUNCTIONS implementation looks at the last two currently inherited classes and sets up an indirect function call view the second last class inherited, e.g.: do_configure calls gnomebase_do_configure gnomebase_do_configure calls autotools_do_configure This intermediary doesn't seem to serve a useful purpose. This patch therefore makes builds deterministic and fixes various cache problems and indirection by removing the intermediaries and simply performing directly mapping for the cases where its needed. (Bitbake rev: 9fc98f96f0e0320beda0ce9546275a99336732c1) Signed-off-by: Richard Purdie