summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/data.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: ast/data/codeparser: Add dependencies from python module functionsRichard Purdie2022-12-171-4/+11
| | | | | | | | | | | | | | | | | | | | Moving code into python modules is a very effective way to reduce parsing time and overhead in recipes. The downside has always been that any dependency information on which variables those functions access is lost and the hashes can therefore become less reliable. This patch adds parsing of the imported module functions and that dependency information is them injected back into the hash dependency information. Intermodule function references are resolved to the full function call names in our module namespace to ensure interfunction dependencies are correctly handled too. (Bitbake rev: 605c478ce14cdc3c02d6ef6d57146a76d436a83c) (Bitbake rev: 91441e157e495b02db44e19e836afad366ee8924) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Tweak code layoutRichard Purdie2022-12-081-25/+25
| | | | | | | | | | Make a small change in the layout of the code in build_dependencies which makes subsequent patches easier to read. No functionality change, just moving the function definitions to the start of the function block. (Bitbake rev: fff13b1e5e8397130b4378e0ba2301336ec651a2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Drop obsolete pydoc/path codeRichard Purdie2022-11-291-5/+0
| | | | | | | | | | This code looks like it is from a time when the data module was executable. Nobody does that now and this usage of pydoc is long since obsolete/broken so clean up the code which doesn't do anything useful. (Bitbake rev: 6f4ef770641a9657edaf8618f4c86dfb1116622c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Switch to use frozensets and optimizeRichard Purdie2022-11-231-8/+6
| | | | | | | | | | | | | | | | | | | | | Python handles frozensets a little more optimally than normal sets. Once we finish parsing, we don't edit this data so we can convert to them. To do that, we need to stop changing them so process ignore_deps earlier then we can freeze the data and keep it frozen. This has the side effect that we need to be careful to sort the data in some of the variables when calculating the hashes. Overall this does seem to show a decent parsing time speed improvement of 20-25% in a local test but this would be highly setup dependent. Also ensure the sigdata can handle exported frozenset and make it import back to them instead of sets. (Bitbake rev: 19475627c363a52da49ec144422c87448ff2a6c5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/data_smart/build: Clean up datastore finalize/update_data ↵Richard Purdie2022-11-141-7/+5
| | | | | | | | | | | | | references We dropped the update_data calls a while ago. Clean up the code to match the reality and drop the remaining no-op pieces. Update the comments to reflect the slowest operations and let the cookie monster's spirit live on! (Bitbake rev: 584989ed2b5af4e8799571dece0cf94f995ef14e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: drop unused __expand_var_regexp__ and __expand_python_regexp__Mark Asselstine2022-11-101-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | First, commit 81efd77987f6decf256967fa16521a40c14d3518 created a copy of __expand_var_regexp__ and __expand_python_regexp__ when creating the initial version of data_smart.py. A while later commit db1c998b31da06d7f3eb09fc6f59a1915b7b549e dropped all references to these variables from data.py. This leaves us today with two versions of these variables in the global scope. However, only those defined in data_smart.py are being used, in data_smart.py. Unfortunately there was no indication in the commit log for commit db1c998b31da indicating why the variables were left in place despite the functions referencing them were being removed. Additionally data.py imports data_smart, thus the versions of __expand_var_regexp__ and __expand_python_regexp__ defined in data_smart.py would be used by all bitbake code, beyond, potentially, some code in data.py which we know has no references to these variables. To remove any potential confusion around these variables drop the old definitions from data.py. (Bitbake rev: 60f43d0428d43c981b44b6c8d125f77440f6c8f9) Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/cooker: Implement recipe and global classesRichard Purdie2022-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We have some confusion for users since some classes are meant to work in the configuration space (or "globally") and some are meant to be selected by recipes individually. The cleanest way I could find to clarify this is to create "classes-global" and "classes-recipe" directories which contain the approproate classes and have bitbake switch scope between them at the appropriate point during parsing. The existing "classes" directory is always searched as a fallback. Once a class is moved to a specific directory, it will no longer be found in the incorrect context. A good example from OE is that INHERIT += "testimage" will no longer work but IMAGE_CLASSES += "testimage" will, which makes the global scope cleaner by only including it where it is useful and intended to be used (images). (Bitbake rev: f33ce7e742f46635658c400b82558cf822690b5e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Do not depend on vardepvalueexclude flagTomasz Dziendzielski2022-05-161-0/+2
| | | | | | | | | | | | | | If SRC_URI contains python function that extends vardepvalueexclude its value is being tracked by sstate-cache, which can lead to rebuilds if value is set dynamically (for example gerrit replicas). Return empty string if vardepvalueexclude is checked to fix this behaviour. (Bitbake rev: f5f9a7b89a7d8321f03184e61ad6d5ed8d0f840e) Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Fix accidentally added parameterRichard Purdie2022-04-041-1/+1
| | | | | | | | | This was only meant to be added for the handle_contains function in a previous commit, fix it. (Bitbake rev: 7399be398df39bc29e1b5eaac23b29cfae017abd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Ensure vardepsexclude or BB_BASEHASH_IGNORE_VARS covers ↵Richard Purdie2022-04-031-9/+12
| | | | | | | | | | | | | | contains items Adding bb.utils.filter('WARN_QA', 'patch-fuzz', d) when WARN_QA is in BB_BASEHASH_IGNORE_VARS or in vardepsexclude should not add a dependency on WARN_QA. Fix it and add some tests. (Bitbake rev: 6aecc2fe51a52020f6f13be08449e18d42e7a6b5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Rename basehas and taskhash filtering variablesScott Murray2022-02-211-6/+6
| | | | | | | | | | | | | | | | | | | | | In line with the inclusive language migration defined at: https://wiki.yoctoproject.org/wiki/Inclusive_language rename: BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS BB_HASHTASK_WHITELIST -> BB_TASKHASH_IGNORE_TASKS the derived code variables basewhitelist and taskwhitelist have been renamed to basehash_ignore_vars and taskhash_ignore_tasks, respectively. [RP: Added compatibility mapping code and tweaked naming] (Bitbake rev: efaafc9ec2e8c0475e3fb27e877a1c0a5532a0e5) Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 01:27:17 +0000