linux/poky.git/bitbake/lib/bb/parse, branch 1.4_M3

bitbake: parse_py: add ~ to config_regexp

2013-01-22T15:35:06+00:00

- enable the '~' character in bitbake variables (Bitbake rev: 7c15ff1d50d7b601414f1d55c90e3c59981a0876) Signed-off-by: Constantin Musca 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: bitbake: data_smart.py and friends: Track variable history

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

This patch adds tracking of the history of variable assignments. The changes are predominantly localized to data_smart.py and parse/ast.py. cooker.py and data.py are altered to display the recorded data, and turn tracking on for the bitbake -e case. The data.py update_data() function warns DataSmart.finalize() to report the caller one further back up the tree. In general, d.setVar() does what it used to do. Optionally, arguments describing an operation may be appended; if none are present, the operation is implicitly ignored. If it's not ignored, it will attempt to infer missing information (name of variable, value assigned, file and line) by examining the traceback. This slightly elaborate process eliminates a category of problems in which the 'var' member of the keyword arguments dict is set, and a positional argument corresponding to 'var' is also set. It also makes calling much simpler for the common cases. The resulting output gives you a pretty good picture of what values got set, and how they got set. RP Modifications: a) Split from IncludeHistory to separate VariableHistory b) Add dedicated copy function instead of deepcopy c) Use COW for variables dict d) Remove 'value' loginfo value and just use 'details' e) Desensitise code for calling order (set 'op' before/after infer_caller_details was error prone) f) Fix bug where ?= "" wasn't shown correctly g) Log more set operations as some variables mysteriously acquired values previously h) Standardise infer_caller_details to be triggered from .record() where at all possible to reduce overhead in non-enabled cases i) Rename variable parameter names to match inference code j) Add VariableHistory emit() function to match IncludeHistory k) Fix handling of appendVar, prependVar and matching flag ops l) Use ignored=True to stop logging further events where appropriate (Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d) Signed-off-by: Peter Seebach Signed-off-by: Richard Purdie

bitbake: bitbake: data_smart.py and friends: Track file inclusions for bitbake -e

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

This code adds inclusion history to bitbake -e output, showing which files were included, in what order. This doesn't completely resolve timing questions, because it doesn't show you which lines of a file were processed before or after a given include, but it does let you figure out what the path was by which a particular file ended up in your build at all. How it works: data_smart acquires a .history member, which is an IncludeHistory; this represents the inclusion of a file and all its inclusions, recursively. It provides methods for including files, for finishing inclusion (done as an __exit__), and for dumping the whole tree. The parser is modified to run includes inside a with() to push and pop the include filename. RP Modifications: a) Split Include and Variable tracking b) Replace deepcopy usage with dedicated copy function c) Simplify some variable and usage (Bitbake rev: b2dda721262da8abb7dc32d019e18fbc32ed8860) Signed-off-by: Peter Seebach 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

bitbake: Revert "BBHandler: Ensure parser state engine is correctly reset for new parsing"

2012-12-07T18:09:01+00:00

This reverts commit 3dc5e896a97154914cee6c47900e3bb2a2627cdb. Signed-off-by: Richard Purdie