summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/data.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: lib/bb/{data, siggen}: Don't warn on SkipRecipe exceptionsNathan Rossi2017-04-121-0/+2
| | | | | | | | | | | | Recipes/variables that raise a SkipRecipe exception are intentionally skipped, and should not generate warnings. [YOCTO #11319] (Bitbake rev: edf6e6094a9f7ad4b2ba06eef8fd34756edbedce) Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/data: fix dependency handling for contains and multiple valuesPaul Eggleton2017-04-051-4/+6
| | | | | | | | | | | | | | | | The code that determines variable dependencies uses the codeparser to find references to "contains" type operations e.g. bb.utils.contains(). That function can take multiple items to check, and all specified items have to be present. However this code didn't handle that - it assumed that only one item would be specified and thus it was treating the multiple items as a single item with spaces in between. Split the value and check if all words are present in order to determine whether the check is "set" or "unset". (Bitbake rev: 272f1245acdd4fb85cb78612aa03627a9c246d8f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/cooker: Sort output data shown by -eRichard Purdie2017-03-221-1/+1
| | | | | | | | | | Displaying the environment data in a sorted manner makes it easier to compare data between different setups and means you can know where to find specific entries. (Bitbake rev: baa417e44b009149eb1dfb07d5a488740b6e68ef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data.py: sort exported variablesJuro Bystricky2017-03-221-1/+1
| | | | | | | | | | | | | Various run.do_xxx files export dozens of variables. Presently they are in random order. Among other things, this makes it difficult to compare two files for relevant changes. This patch ensures they are enumerated/printed in a sorted (alphabetical) order. (Bitbake rev: 27b501d1400d1942b5ba9f35218ca7aacd9bfefe) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: remove True option to getVarFlag callsJoshua Lock2016-11-301-4/+4
| | | | | | | | | | | | | | getVarFlag() now defaults to expanding by default, thus remove the True option from getVarFlag() calls with a regex search and replace. Search made with the following regex: getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\) (Bitbake rev: c19baa8c19ea8ab9b9b64fd30298d8764c6fd2cd) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: remove True option to getVar callsJoshua Lock2016-11-301-9/+9
| | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (Bitbake rev: 3b45c479de8640f92dd1d9f147b02e1eecfaadc8) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Drop deprecated old style bitbake APIRichard Purdie2016-11-231-53/+0
| | | | | | | | | | | | | | | | The old style bb.data.getVar/setVar API has long since been deprecated in favour of d.getVar/setVar and friends. Now we're about to change the default expansion parameter, drop the old APIs to simplify the transition and ensure everyone is using the new style functions. Conversion is trivial if there are remaining stragglers. I've left bb.data.expand() for now since its more widely used but would make a good follow up patch series. (Bitbake rev: 1825604d46fcd29fad6cfd325f1cb1e1b457d2c9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: fix exception handling in exported_vars()Markus Lehtonen2016-11-041-3/+5
| | | | | | | | | | | | | | | Fix a bug where a totally wrong value of a variable would be exported if an exception happened during d.getVar(). Also, print a warning if an exception happends instead of silently ignoring it. It would probably be best just to raise the exception, instead, but use the warning for now in order to avoid breaking existing builds. [YOCTO #10393] (Bitbake rev: f639f06cfa280adcc25438387567966271b9b2c3) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Fix handling of vardepvalueexcludeRichard Purdie2016-10-011-1/+1
| | | | | | | | | | | | | The value used for exclusion was always being expanded. This is actually a bad idea since in most cases you'd want to exclude an unexpanded value and makes it impossible to use the variable as intended. This adjusts things so the value is not expanded and we can correctly remove things from checksums much more easily. (Bitbake rev: 81bc8201c475d2b6bef0168573915ad0140f6dad) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Implement support for per-task exportsChristopher Larson2016-05-191-1/+3
| | | | | | | (Bitbake rev: 4506ccf1495c6ed6e8ed678f4baa166bc94d1761) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update logger.warn() -> logger.warning()Richard Purdie2016-05-111-1/+1
| | | | | | | | | | python deprecated logger.warn() in favour of logger.warning(). This is only used in bitbake code so we may as well just translate everything to avoid warnings under python 3. Its safe for python 2.7. (Bitbake rev: 676a5f592e8507e81b8f748d58acfea7572f8796) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.{cooker, data}: only emit a var as python if 'func' is setChristopher Larson2016-05-061-2/+2
| | | | | | | | | | | | This avoids a common issue where PACKAGECONFIG is emitted as a function in bitbake -e when the 'python' flag exists. It isn't a python function unless both 'func' and 'python' are set. This aligns with the behavior of emit_func_python. (Bitbake rev: c5e45063cb3ae17bbe3304ea5e712bd76e686c4a) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/data: Don't expand python functions before execution [API change]Richard Purdie2016-02-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, if you have some python code like: X = "a" def somefunction(d): d.setVar("X", "b") d.setVar("Y", "${X}") then any sane person would expect that Y = "b" at the end of the function. This is not the case, Y = "a". This is due to the python function being expanded before execution, the executed code would read d.setVar("Y", "a"). This understandably confuses people, it also makes it near impossible to write ${} in a python function without unintended things happening. I think there is general agreement we should fix this and standardise on non-expansion of python functions. We already don't expand anonymous python (mostly). I've checked OE-Core with buildhistory before and after this change and there were a small number of issues this exposed which I've sent patches for. I propose we default to not expanding python code and then deal with any consequences from that if/as/where identified. This will improve new user understanding and usability of the system, it also allows several long standing weird expansion issues to be fixed. (Bitbake rev: 8bf33a8e92c0e188fa392030025756196c96fcbb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Don't expand python functions for variable dependenciesRichard Purdie2016-02-101-6/+6
| | | | | | | | | | | | | Expanding python functions for variable dependencies doesn't really make sense, not least since this causes execution of any inline python, it also makes it impossible to write expressions like d.expand("${X}") of d.setVar("X", "${Y}") which may have the wrong values if expanded now. This starts to standardise the approach across bitbake for handling python code. (Bitbake rev: 765a2480dbe288f64562a9611dd93b6b6dd0a64e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Add expansion parameter to getVarFlagRichard Purdie2016-02-041-12/+12
| | | | | | | | | | | | | | | This sets the scene for removing the default False for expansion from getVarFlag. This would later allow True to become the expand default. On the most part this is an automatic translation with: sed -e 's:\(\.getVarFlag([^,()]*, [^,()]*\)):\1, False):g' -i `grep -ril getVar *` There should be no functional change from this patch. (Bitbake rev: 7c3b99c6a716095af3ffce0b15110e91fb49c913) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data.py: avoid double newlines at the end of functions in emit_var()Andre McCurdy2016-01-301-0/+1
| | | | | | | | | | A newline is always appended to the function body when it's written out, so strip any trailing newlines which may be there already. (Bitbake rev: 8a3f50936113e15d2f2822f6aee494204fa1c24f) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Drop misleading ExpansionError exceptionRichard Purdie2016-01-061-1/+2
| | | | | | | | | | | | | This codepath can be triggered by a python indentation error for example. Showing it as an ExpansionError is misleading. Change the code to add a warning about where the failure came from (in particular giving the variable key name that triggered it) but raise the proper exception. (Bitbake rev: d49d46533704e8b4404e29abfb5a7383d704c91a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Pass lineno/filename data from build_dependenciesRichard Purdie2016-01-061-2/+2
| | | | | | | | | If parse_python() fails, the output is confusing. Passing in the extra file/line data isn't expensive and improves readability significantly. (Bitbake rev: a4bb753488d322e0e31c31d6377ba780f2f824c4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Improve override history loggingRichard Purdie2015-07-241-1/+1
| | | | | | | | | | | | | | | | | | Calling record() for each override alteration is slow. Since we now expand overrides dynamically we don't have to record the log data at each alteration, we can instead print it directly from the existing data stores at variable history print time using the exact same data stores. This massively improves performance of the data store when parsing with bitbake -e for example, it will improve memory overhead as well. The only downside is that VariableHistory has to poke into the datastore for some of its data but that seems an acceptable tradeoff rather than double caching. (Bitbake rev: 100b447a161ef20fa559e39516cd32fa78e38262) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Clean up datastore accesses and True/False valuesRichard Purdie2015-07-241-20/+20
| | | | | | | | | | | | We should use the d.xxxVar syntax rather than the older function style. Also replace 0/1 with the more pythonic True/False. No functionality changes. (Bitbake rev: 90fdd69cca951f8bd2ff634f3b42fccd4fc03095) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Add newline after the last export in emit_funcAndre McCurdy2015-07-241-1/+2
| | | | | | | | | | | | | Minor formatting improvement in generated shell scripts. Add a newline after the last export emitted by emit_func. Also, remove chance of putting an extra newline in the middle of the exports, since we never want to do that. (Bitbake rev: 5117d9b5d32d5d81adf70fa3e3feac9cef654240) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add explict getVar param for (non) expansionRichard Purdie2015-06-231-1/+1
| | | | | | | | | | | | | | Rather than just use d.getVar(X), use the more explict d.getVar(X, False) since at some point in the future, having the default of expansion would be nice. This is the first step towards that. This patch was mostly made using the command: sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *` (Bitbake rev: 659ef95c9b8aced3c4ded81c48bcc0fbde4d429f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Make expandKeys deterministicRichard Purdie2015-05-291-1/+1
| | | | | | | | | | | | | At least in theory, the order the keys are expanded in can make a difference, particularly if there is key overlap. We also want to ensure that any underlying base key is processed before any overridden version of that variable (FOO before FOO_x) which helps the update_data removal code I've been testing. (Bitbake rev: 863b6add24c211d64ba7931647084321f2d65889) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Revert expandKeys warning moveRichard Purdie2015-05-291-6/+5
| | | | | | | | | | | This was incorrect, it *must* be done next to the rename as a previous may overlap with the current one and we need to detect this case. I'll add a test case to better catch this problem in future. (Bitbake rev: 5e9d0911cd86e980ab310cc0d79c9383fbc2c844) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Clean up expandKeys None value handlingRichard Purdie2015-05-291-2/+2
| | | | | | | | | | | This comparison is interesting even in the case of empty vales. Enabling this warning actually found a bug in the metadata in avahi. Make the code handle None specifically and also remove the dead code path in the second if statement. (Bitbake rev: a4cd4c56284812efb2a2bc0c8667ddad073f8e94) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Move warning code to the first loop for performanceRichard Purdie2015-05-261-5/+5
| | | | | | | | | By doing this we can take advantage of the expansion cache before starting write operations on the data store. (Bitbake rev: 702b42a47904f2378dd819e7463b3206883c2651) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: escape '$' in shell variable assignmentRichard Tollerton2014-12-181-0/+1
| | | | | | | | | | | | | Running bitbake inside make results in the exported environment variable MAKEOVERRIDES="${-*-command-variables-*-}", which the shell chokes on when trying to expand it. But of course, it probably shouldn't have been trying to expand it in the first place -- so just escape the dollar sign. (Bitbake rev: 18cd0ce6a55c9065c3f1bf223b47d817b5efcd8f) Signed-off-by: Richard Tollerton <rich.tollerton@ni.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Handle BASH_FUNC shellshock implicationRichard Purdie2014-12-091-0/+7
| | | | | | | | | | | | | | | | | | | The shellshock patches changed the way bash functions are exported. Unfortunately different distros used slightly different formats, Fedora went with BASH_FUNC_XXX()=() { echo foo; } and Ubuntu went with BASH_FUNC_foo%%=() { echo foo; }. The former causes errors in dealing with out output from emit_env, the functions are not exported in either case any more. This patch handles things so the functions work as expected in either case. [YOCTO #6880] (Bitbake rev: f28f37220e7787721a31b659521a1c44ebea92bf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/data: Write out more complete python run filesRichard Purdie2014-08-281-0/+35
| | | | | | | | | | | | | Currently the output in the python task/function run files is rather incomplete and effectively useless. This enhances the code to take advantage of the bitbake's dependency tracking and extend the output to include dependencies. This makes the files more usable for debugging purposes. Since this only happens at python function execution time, the overhead is minimal in the grand scheme of things. (Bitbake rev: 02667e048c3e632f857c87177c0022eaf5481802) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/*.py: Typo fixes/grammar/comment fixes, nothing functional.Robert P. J. Day2014-08-251-3/+3
| | | | | | | (Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953) Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: add vardepvalueexclude varflagPaul Eggleton2014-03-061-1/+7
| | | | | | | | | | | | | | | | | | On rare occasions it's useful to be able to exclude a part of a variable's value from the variable's signature; for example if you want to add an item to a list sometimes and not have the signature of the variable change depending on whether the item is in the list or not. The initial intended use case for this in OpenEmbedded is to allow adding a function to SSTATEPOSTINSTFUNCS in buildhistory.bbclass and not have that change any task signatures (so adding and removing INHERIT += "buildhistory" won't lead to any rebuilds). Part of the fix for [YOCTO #5897]. (Bitbake rev: f803bf8cfefafcbe212442e66b301ccd9c5aa2a5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Account for pre/postfunc functions when calculating dependenciesRichard Purdie2014-02-041-2/+6
| | | | | | | | | | | | | | pre/postfuncs were not being added to checksums. This meant that when reconfiguration occurred, tasks were not always being rerun when they should. This include sstate functions as well as systemd's do_install function in the OE metadata. With the addition of postfuncs, its possible a shell task can have a python pre/postfunc so we have to guard against this when generating shell output in emit_func. (Bitbake rev: b84d010144de687667cf855ddcb41c9b863c236e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Ensure we add the contains keys in a particular orderRichard Purdie2013-12-091-2/+2
| | | | | | | | | | If we don't sort the data, the values can reorder changing the signatures meaning we get confused builds and significant cache misses. (Bitbake rev: 8f453bb11d72afc90a986ac604b3477d97eaf9a8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/codeparser: Improve handling of contains functionsRichard Purdie2013-11-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the current frustrations with the sstate checksums is that code like base_contains('X', 'y',...) adds a full dependency on X and varies depend even on whitespace changes in X. This patch adds special handling of the contains functions to expand the first parameter and check for the flag specified by the second parameter (assuming its a string). The result is then appended to the value of the variable with a "Set" or "Unset" status. If the flag is added/removed, the stored variable value changes and hence the checksum changes. No dependency on X is added so it is free to change with regard to other flags or whitespace. This code is far from ideal, ideally we'd have properly typed variables however it fixes a major annoyance of the current checksums and is of enough value its worth adding in a stopgap solution. It shouldn't significantly restrict any propely typed variable implementation in future. (Bitbake rev: ed2d0a22a80299de0cfd377999950cf4b26c512e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Fix output inconsistencies for emit_varRichard Purdie2013-11-251-2/+2
| | | | | | | | | | | | | | | | | | VAL = "" (not shown) VAL = " " (shown as "") VAL = " x" (shown as "x") would all show up rather differently to what would be expected in the bitbake -e output. This fixes things so they appear consistently. The output for running some shell functions may also change slightly but shouldn't change in a way that is likely to cause problems. [YOCTO #5507] (Bitbake rev: fcba5ef0053dc0ef5360e4912609e5d52f5046b0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Optimise flag exclusion list handlingRichard Purdie2013-09-171-5/+4
| | | | | | | | | Move the variable lookup to the outer loop for performance, replacing a now unneeded parameter (after the previous changes). (Bitbake rev: 8a59a8707cecbde257fca169775ce8ff7709928b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Optimise flag lookup in build_dependenciesRichard Purdie2013-09-171-2/+5
| | | | | | | | | When looking up flag variable dependencies, large chunks of the function aren't needed. Optimise the function flow accordingly for speed. (Bitbake rev: 1bf3aee698ad35f6815ea2c75471a96511a29d55) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Optimise build_dependencies a littleRichard Purdie2013-09-171-11/+10
| | | | | | | | | Instead of multiple calls to getVarFlag, make one call to getVarFlags, only expanding the flags that need to be expanded. This improves performance. (Bitbake rev: eba1e9545cc933820d40de96f023b2307b3c4d0b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Cache an list of export variablesRichard Purdie2013-09-171-1/+1
| | | | | | | | | Compute a cache of the list of potential export variables so that we don't have to compute the list from scratch. (Bitbake rev: f41f46f7eaa6889edeb3a4e4ddedc07084686c60) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Use direct iteration, not keys()Richard Purdie2013-09-171-2/+2
| | | | | | | | | | | Profiling shows the creation of keys() has overhead and we're better using an iterator rather than the memory associated with the huge list of keys when iterating the whoe datastore. We minimise the number of times we do this to twice only per recipe. (Bitbake rev: e63448d9ee331b0f45fb9a0197d0dbee49eb2fa0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Be explicit in data_db checkRichard Purdie2013-09-171-1/+1
| | | | | | | | | | | The if statement current causes the size of parent to be calcuated which is like a len() operation on a datastore. Since we're only interested whether the value is none, checking explictly for this gives a small performance gain. (Bitbake rev: 43a245bde318545ea75ca4ce7894395c1cf9b32a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob & bitbake: append a value to a variable from hob throught bitbakeCristiana Voicu2013-08-061-0/+4
| | | | | | | | | | | | It was necessary to append ${TOPDIR}/recipes/images to BBFILES. Implemented the mechanism to append a value to a variable: a command and the method in cooker. [YOCTO #4193] (Bitbake rev: 4aedbee90bd92395c2460a68702e6ede00e256c9) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Ensure dependencies of subfunctions are accounted forRichard Purdie2013-05-221-0/+1
| | | | | | | | | | | | Currently we account of the top level function's vardeps but not those of any subfunction. This would imply we'd have to manually write the dependencies of all parent functions which would be crazy. This patch adds the dependencies to fix the issue. (Bitbake rev: 658008cc6a8acd5c1f26877c9444c96002db01e7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: fix performance regressionPaul Eggleton2013-04-151-2/+2
| | | | | | | | | | | | | | BitBake commit 7c568132c54a21161de28907159f902462f1e2bb resulted in a fairly serious performance regression during parsing, almost doubling the time taken to do a full parse and almost certainly impacting performance during building. The expandKeys function is called frequently, and if we avoid using keys() and instead just use the normal variable lookup mechanism, performance is restored. (Bitbake rev: 034b392e9877309f15940b258fc2c16f16fb40b5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data.py: Add a warning when expandKeys overwrites an existing keyMark Hatle2013-04-101-0/+5
| | | | | | | | | | | | | | | | | | | When two variables are defined as: ${var} = "bar" foo = "foobar" The value of 'foo' when ${var} == foo becomes indeterminate. We want to warn a user when this situation has been encountered so they can take corrective actions. In the above example usually foo == bar, unless multilibs are enabled. Then ml-foo = "ml-foobar". (Bitbake rev: 7c568132c54a21161de28907159f902462f1e2bb) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: data_smart.py and friends: Track variable historyPeter Seebach2013-01-181-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/data: Standardise some setVar access formatsRichard Purdie2013-01-181-3/+3
| | | | | | (Bitbake rev: e12c1a485f96a4701144ac81179ae1af348e5bf3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Ensure emit_func honours vardeps flagRichard Purdie2012-12-171-0/+1
| | | | | | | | | | | | | | | Currently, calling a shell function using exec_func may result in dependent functions being missing, if the shell parser can't detect the dependency, even if it was specified with the vardeps flag. This patch ensures the function looks at the flag and considers it when deciding which other functions need to be output. [YOCTO #3561] (Bitbake rev: a906c94328b040d5076571bd593b57be7ee403a5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBhandler/data: Fix __inherit_cache duplicationRichard Purdie2012-12-111-2/+4
| | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/data.py: improve output for expansion errorsPaul Eggleton2012-09-271-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Instead of logging the function/variable separately as a NOTE when failing to expand, re-raise ExpansionError with more contextual information. This means that the full details are reported in Hob as well as actually reporting the original error message in any UI where we previously did not. For example, we used to get this with tab/space indentation issues in a python function: NOTE: Error expanding variable populate_packages ERROR: Unable to parse /path/to/recipename.bb Now, we will get this: ERROR: ExpansionError during parsing /path/to/recipename.bb: Failure expanding variable populate_packages: IndentationError: unindent does not match any outer indentation level (<string>, line 4) Fixes [YOCTO #3162]. (Bitbake rev: ce5c7a95a359cdaecab7c4a519ad4f9df029da82) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-11 10:02:18 +0000