linux/poky.git/bitbake/lib/bb/parse/parse_py, 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: 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

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

2012-12-07T17:13:13+00:00

The classes variable in particular could be in an odd state if parsing of a previous recipe had abruptly ended. (Bitbake rev: 3dc5e896a97154914cee6c47900e3bb2a2627cdb) Signed-off-by: Richard Purdie

bitbake: parse/ConfHandler: Add negative lookahead to spot some quoting problems

2012-09-28T10:15:04+00:00

Syntax like: FOO = "bar" # eek" would result in FOO taking the value 'bar" #eek' which is clearly not the intention. Whilst our metadata is riddled with mixtures of even quotes like: FOO = "d.getVar("X")" odd numbers of quotes seem rare. This patch adds detection of one odd quote which we don't have any of in OE-Core so it seems a valid sanity improvement. (Bitbake rev: 5f892d9b083550e20e37576070ec7d1a94cc88fe) Signed-off-by: Richard Purdie