linux/poky.git/bitbake/lib/bb/parse, branch 1.6_M4

bitbake: ast: Fix support for anonymous methods in wildcard .bbappend files

2014-02-24T12:42:40+00:00

When using wildcard .bbappend files with anonymous methods in them, bitbake/python fails to parse the generated code since the '%' is encoded in the generated method name. Fix this by including '%' in the convert-to-underscore list during method name mangling. While we're at it, move the method name mangling translation table to a class variable, as suggested by Chris Larson. [YOCTO #5864] (Bitbake rev: 537f1f9bbe110acc9848ef95f43468c07d87af79) Signed-off-by: Jacob Kroon Signed-off-by: Richard Purdie

bitbake: parse: make vars_from_file return None for non-recipes

2014-02-17T15:34:45+00:00

It doesn't really make sense to set PN from .conf files, for example. More concretely, this avoids the config hash changing unnecessarily within Hob due to PN effectively changing (since bblayers.conf is parsed first and then .hob.conf). (Bitbake rev: 22e03ef7ac9bb6b7245250347ae9c10c19f1d74e) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: build/ast: Create strong task add/del API in bb.build

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

Currently its near impossible to control task addition/deletion from metadata context. This adds stong add/deltask API to bb.build which is traditionally where it resided. The rather broken remove_tasks function was removed, it didn't appear to do anything useful or have any users. This allows us to clean up hacks currently in use in metadata and use standard API for it instead. (Bitbake rev: bf7138dd38fc1f8efca80891198e3422fef64093) Signed-off-by: Richard Purdie

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: parse: Return IOError when including file with absolute path

2013-08-26T10:29:46+00:00

* resolve_file was behaving different when relative and absolute paths were passed to it * include relative-path/non-existent-file.inc works correctly resolve_file throws IOError, BBHandler.py:handle() doesn't catch it, ConfHandler.py:include() catches IOError and shows: DEBUG: CONF file 'relative-path/non-existent-file.inc' not found * include /absolute-path/non-existent-file.inc was failing, because resolve_file just returns fn, BBHandler.py:handle() calls bb.parse.mark_dependency(d, abs_fn) which throws: OSError: [Errno 2] No such file or directory: '/absolute-path/non-existent-file.inc' and parsing fails. Ad isfile() test for absolute fn and throw IOError to make resolve_file behavior consistent for both paths. * I know we had some issues with -b relative-path-to-recipe.bb and absolute path, so consider this patch only as RFC and documentation of this problem * Catch OSError too in ConfHandler.py:include() e.g. in case the file exists, but user cannot read it or something like that. (Bitbake rev: b0bbd89a4f0b98fa1ab28b8e0526cd9ddb76fa57) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

bitbake: bitbake: python funcname can not include special character @

2013-06-27T09:06:09+00:00

[YOCTO #4772] When path:file change to python function, it maybe include '@' character. So, add the special character to change to '_' for avoid error. (Bitbake rev: 684bc6dcb11ecb1fd7a4d25c08909ad9879e8342) Signed-off-by: Li Wang Signed-off-by: Richard Purdie

bitbake: bitbake: Add event mask flag support

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

Add a flag to event handlers which lists the events a given handler wishes to process. By default event handlers recieve all events but this means we can stop running code in many cases if we know it doesn't want the event. This is part of the fix for YOCTO #3812, but implements filtering only for class event handlers; the other part (events filter for UIs) will be the subject of a different patch. (Bitbake rev: 074003a4e7530a72863b9c685fc5c31b0f08c039) Signed-off-by: Bogdan Marinescu 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