summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/data.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: lib/bb: Fix string concatination potential performance issuesRichard Purdie2021-11-031-12/+12
| | | | | | | | | | | | | | | | Python scales badly when concatinating strings in loops. Most of these references aren't problematic but at least one (in data.py) is probably a performance issue as the issue is compounded as strings become large. The way to handle this in python is to create lists which don't reconstruct all the objects when appending to them. We may as well fix all the references since it stops them being copy/pasted into something problematic in the future. This patch was based on issues highligthted by a report from AWS Codeguru. (Bitbake rev: d654139a833127b16274dca0ccbbab7e3bb33ed0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Ensure functions are defined in a deterministic orderRichard Purdie2021-10-031-1/+1
| | | | | | | | | | | When writing functions into shell scripts, write then in a deterministic order. This is unlikely to affect anything at runtime but it does change the signatures of the generated useradd postinst scripts in OE-Core and is a good thing to be consistent about in general. (Bitbake rev: 8a181dc8f3c8c9c9885ea3011cb234321a296d92) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: emit filename/lineno information for shell functionsChris Laplante2020-08-081-0/+6
| | | | | | | | | | | | | | | | | | Make it easier for users to debug shell task failure by including some breadcrumbs in the emitted .run file that (hopefully) points to the .bb/.bbclass file where the shell function was defined. Unfortunately this won't work with functions with _append or _prepends, since BitBake wipes the filename/lineno information. This shouldn't be too hard to fix; for now, you'll just see comments like this for such functions: [YOCTO #7877] (Bitbake rev: 9747211cbb45401cbf4dd0409e9c80c648a178c6) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Don't expand ignored variablesRichard Purdie2020-04-061-2/+2
| | | | | | | | | | | | | | | | | | If a variable is in the signature whitelist, we'd currently expand it, then later ignore the data. This is problemtic for code which has effects when expanded, recently source date epoch in OE-Core for example. We don't actually need to do this, if we pass the whitelist into the earlier function it can avoid the expansion. This also also give a small performance boost since we avoid running code in some cases. [YOCTO #13581] (Bitbake rev: f483ee4a869fb1dafbe4bdf2da228cdaa40b38bd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: amend code to use proper singleton comparisons where possibleFrazer Clews2020-01-191-1/+1
| | | | | | | | | | | amend the code to handle singleton comparisons properly so it only checks if they only refer to the same object or not, and not bother comparing the values. (Bitbake rev: b809a6812aa15a8a9af97bc382cc4b19571e6bfc) Signed-off-by: Frazer Clews <frazer.clews@codethink.co.uk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/utils: Drop bb.build.FuncFailedRichard Purdie2019-08-061-1/+1
| | | | | | | | | | | | | Its hard to see what this exception adds in the current codebase. The logfile attribute is effectively ignored, the exception doesn't serve a defined purpose and mostly seems to be worked around. Remove it entirely. If this does cause output problems, we'll figure out better ways to address those. (Bitbake rev: cfeffb602dd5319f071cd6bcf84139ec77f2d170) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Clean up task reference formatsRichard Purdie2019-08-061-1/+1
| | | | | | | | | | | | | | | | | | Currently siggen uses the format "<filename>.<taskname>" for referencing tasks whilst runqueue uses "<filename>:<taskname>". This converts to use ":" as the separator everywhere. This is an API breaking change since the cache is affected, as are siginfo files and any custom signature handlers such as those in OE-Core. Ultimately this will let us clean up and the accessor functions from runqueue, removing all the ".rsplit(".", 1)[0]" type code currently all over the place. Once a standard is used everwhere we can update the code over time to be more optimal. (Bitbake rev: 07e539e1c566ca3434901e1a00335cb76c69d496) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Strip old editor directives from file headersRichard Purdie2019-05-041-2/+0
| | | | | | | | | | There are much better ways to handle this and most editors shouldn't need this in modern times, drop the noise from the files. Its not consitently applied anyway. (Bitbake rev: 5e43070e3087d09aea2f459b033d035c5ef747d0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Drop duplicate license boilerplace textRichard Purdie2019-05-041-13/+0
| | | | | | | | | | With the introduction of SPDX-License-Identifier headers, we don't need a ton of header boilerplate in every file. Simplify the files and rely on the top level for the full licence text. (Bitbake rev: 695d84397b68cc003186e22f395caa378b06bc75) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add initial pass of SPDX license headers to source codeRichard Purdie2019-05-041-0/+2
| | | | | | | | | | | | | | | | | This adds the SPDX-License-Identifier license headers to the majority of our source files to make it clearer exactly which license files are under. The bulk of the files are under GPL v2.0 with one found to be under V2.0 or later, some under MIT and some have dual license. There are some files which are potentially harder to classify where we've imported upstream code and those can be handled specifically in later commits. The COPYING file is replaced with LICENSE.X files which contain the full license texts. (Bitbake rev: ff237c33337f4da2ca06c3a2c49699bc26608a6b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Switch md5 -> sha256Richard Purdie2019-01-081-1/+1
| | | | | | | | | | Similarly to the codeparser change, change to sha256 hashes due to worries over collisions. The main impact of this change is slightly slower parsing time as well as longer sstate file names. (Bitbake rev: 66f1b766997d53b4375fdd25719b1175f3828903) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: BBHandler: Check tab indentation for python codeRobert Yang2018-12-051-2/+0
| | | | | | | | | | | | | | | | | | The previous check was in data.py which only can check code like "python funcname()" in the dependency chain, but there are 3 kinds of python functions: - python() - def py_funcname() - python funcname() Add the checking to BBHandler to check and warn for all of them. The warning looks like: WARNING: /path/to/recipes-core/busybox/busybox_1.29.2.bb: python should use 4 spaces indentation, but found tabs in busybox.inc, line 75 (Bitbake rev: 0cdc5b81fc1f5e5281a525a657e420ebc3bb9e90) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Extract task hash generation code into a functionRichard Purdie2018-10-181-0/+38
| | | | | | | | | By creating a standalone function, we can add better functional testing of this code. (Bitbake rev: 796a20d24dc18479de1975a37b9e52a5ac75c73f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: data: Ensure task checksums account for remove dataRichard Purdie2018-10-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Currently remove operations are not being accounted for in the task checksums. This is a fairly serious oversight and needs to be fixed. To do so, we need internal data from getVarFlag combined with the expanded variable data so that only "active" remove operators are accounted for in the task checksum. We can get this from the new optional removes attribute in the returned parser object. The code can then use the data on active remove operators to account for the removals in task checksum but only when the removal is active. We have to be careful here not to reference any expanded data since this may for example contain build paths. This means we can only map back and reference the unsplit (and hence unexpanded) remove string which may expand to multiple removal values. [YOCTO #12913] (Bitbake rev: 57d2ee17ae83a139a37081eb082e6184fa883581) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/data_smart: Allow getVarFlag to return the variable parser objectRichard Purdie2018-10-181-6/+5
| | | | | | (Bitbake rev: 136100dc932c9019737f927d826955425134010f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Micro performance optimisation tweakRichard Purdie2017-07-081-1/+1
| | | | | | | | | The datastore can assume internal API, this just removes the function indirection overhead involved in this very common codepath (800,000 calls in parsing OE-Core). (Bitbake rev: 9a36531ed2b2881a65e5d39ee4b68d2bb392ed78) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-11 20:44:06 +0000