summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/parse/parse_py/BBHandler.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: BBHandler/ast: Improve addtask handlingRichard Purdie2024-08-131-16/+25
| | | | | | | | | | | | | | | | | | The recent addtask improvement to handle comments complicated the regex significantly and there are already a number of corner cases in that code which aren't handled well. Instead of trying to complicate the regex further, switch to code logic instead. This means the following cases are now handled: * addtask with multiple task names * addtask with multiple before constraints * addtask with multiple after constraints The testcase is updated to match the improvements. (Bitbake rev: 417016b83c21fca7616b2ee768d5d08e1edd1e06) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Handle comments in addtask/deltaskRichard Purdie2024-08-131-2/+2
| | | | | | | | | | | | | | | Technically our syntax would allow for comments after an addtask/deltask. Currently these get silently processed in various ways by the code which is bad. Tweak the regex to drop any comments and add test cases to ensure this continues to work in the future. [YOCTO #15250] (Bitbake rev: 64f8796e55a8826ffec0d76b993c8256713f67a3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Handle unclosed functions correctlyRichard Purdie2024-04-141-1/+7
| | | | | | | | | | | | | | | | | A function accidentally defined as: somefunction() { : } which is unclosed due to the space at the end, would currently silently cause breakage. Have the parser throw and error for this. [YOCTO #15470] (Bitbake rev: a7dce72da6be626734486808f1b731247697e638) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ast/BBHandler: Add inherit_defer supportRichard Purdie2024-01-181-1/+9
| | | | | | | | | | | | | | | | | | | | | | Add support for an inherit_defer statement which works as inherit does but is only evaulated at the end of parsing. This allows conditional expressions to be evaulated 'late' meaning changes to PACKAGECONFIG from bbappends can be applied for example. This addresses a usability/confusion issue users have with the current conditional inherit mechanism since they don't realise the condition has to be expanded immediately with the current model. There is a commented out warning we could enable in future which warns about the use of a conditional inherit that isn't deferred. There is a behaviour difference in the placement of the inherit, particularly around variables set using ?= which means wen swapping from one to the other, caution must be used as values can change. (Bitbake rev: 5c2e840eafeba1f0f754c226b87bfb674f7bea29) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Add support for addpylib conf file directive and ↵Richard Purdie2022-12-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BB_GLOBAL_PYMODULES For many years OE-Core has injected it's own python modules into the python namespace using an immediate expansion of a variable in base.bbclass. It also added all entries from BBPATH to sys.path. We really need this to become a first class citizen of the langauge, this new addpylib directive allows that. Usage is of the form: addpylib <directory> <namespace> The namespace is imported and if there is an attribute BBIMPORT, that list of names is iterated and imported too. This mirrors what OE-Core has done for a long time with one difference in implmentation, sys.path is only appended to. This means later imported namespaces can't overwrite an earlier one and can't overwrite the main python module space. In practice we've never done that and it isn't something we should encourage or support. The new directive is only applied for .conf files and not other filetypes as it only makes sense in that context. It is also only allowed in the "base configuration" context of cookerdata since adding it at the recipe level wouldn't work properly due to the way it changes the global namespace. At the same time, move the list of modules to place in the global namespace into a BB_GLOBAL_PYMODULES variable. It is intended that only the core layer should touch this and it is meant to be a very small list, usually os and sys. BB_GLOBAL_PYMODULES is expected to be set before the first addpylib directive. Layers adding a lib directory will now need to use this directive as BBPATH is not going to be added automatically by OE-Core in future. The directives are immediate operations so it does make modules available sooner than the current OE-Core approach. The new code appends to sys.path rather than prepends as core did, as overwriting python standard library modules would be a bad idea and naturally encouraging people to collaborate around our own core modules is desireable. (Bitbake rev: afb8478d3853f6edf3669b93588314627d617d6b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Remove pointless global variable declarationsRichard Purdie2022-11-291-2/+2
| | | | | | | | | | These are static regex compilations which don't change or a standard module import (bb). There is noneed to declare them as global so drop the pointless code which doesn't do anything. (Bitbake rev: 09a4c159e3fd184f730821e7bd99916b0d28dc70) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/cooker: Implement recipe and global classesRichard Purdie2022-08-121-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: BBHandler: Make inherit calls more directlyRichard Purdie2022-08-121-1/+4
| | | | | | | | | | | Rather than recursing into the conf handler code, simply call into the parse code directly when inheriting files as we've already resolved the paths and don't need anything the other codepath brings. This makes the codepath clearer at the expense of some slight duplication. (Bitbake rev: 0f4f3af6d93a0018df58b8a1d8d423c78ba6526d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Allow earlier exit for classes not foundRichard Purdie2022-08-121-0/+3
| | | | | | | | | Rather than relying on later code to error if the class isn't found, exit earlier and more clearly from a code perspective. (Bitbake rev: f7c55c8147329670fd5bc55b1ae3f47f25b89bab) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ConfHandler/BBHandler: Improve comment error messages and add testsRichard Purdie2022-07-041-2/+2
| | | | | | | | | | | | | | | | | | | Currently if you trigger one of the comment errors, the newline characters are stripped and the line numbers are incorrect. In one case it prints the empty line which is also unhelpful. Rework the code around these errors so the line numbers are correct and the lines in question are more clearly displayed complete with newlines so the user can more clearly see the error. I also added a couple of simplistic test cases to ensure that errors are raised by the two known comment format errors. [YOCTO #11904] (Bitbake rev: 712da71b24445c814d79a206ce26188def8fce0a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse_py: Drop deprecated function referenceRichard Purdie2021-09-101-3/+0
| | | | | | | | This is now used from bb.parse everywhere so drop this long deprecated reference. (Bitbake rev: aaa5292ef96ea27f505bc5c5a4b1eb4f497ed061) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart/parse: Allow ':' characters in variable/function namesRichard Purdie2021-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is becomming increasingly clear we need to find a way to show what is/is not an override in our syntax. We need to do this in a way which is clear to users, readable and in a way we can transition to. The most effective way I've found to this is to use the ":" charater to directly replace "_" where an override is being specified. This includes "append", "prepend" and "remove" which are effectively special override directives. This patch simply adds the character to the parser so bitbake accepts the value but maps it back to "_" internally so there is no behaviour change. This change is simple enough it could potentially be backported to older version of bitbake meaning layers using the new syntax/markup could work with older releases. Even if other no other changes are accepted at this time and we don't backport, it does set us on a path where at some point in future we could require a more explict syntax. I've tested this patch by converting oe-core/meta-yocto to the new syntax for overrides (9000+ changes) and then seeing that builds continue to work with this patch. (Bitbake rev: 0dbbb4547cb2570d2ce607e9a53459df3c0ac284) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: logging: Make bitbake logger compatible with python loggerJoshua Watt2021-02-101-1/+1
| | | | | | | | | | | | | | | | | The bitbake logger overrode the definition of the debug() logging call to include a debug level, but this causes problems with code that may be using standard python logging, since the extra argument is interpreted differently. Instead, change the bitbake loggers debug() call to match the python logger call and add a debug2() and debug3() API to replace calls that were logging to a different debug level. [RP: Small fix to ensure bb.debug calls bbdebug()] (Bitbake rev: f68682a79d83e6399eb403f30a1f113516575f51) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Don't classify shell functions that names start with ↵Tomasz Dziendzielski2021-02-101-1/+1
| | | | | | | | | | | | | | | | | | "python*" as python function If shell function name starts with 'python' or 'fakeroot' parser wrongly assumes it's python/fakeroot function. [YOCTO #14204] Use regex lookahead assertions to check if 'python' expression is followed by whitespace or '(' and if 'fakeroot' is followed by whitespace. (Bitbake rev: b07b226d5d1b3acd3f76d8365bc8002293365999) Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: prompt error when task name contain expressionLee Chee Yang2020-11-081-1/+5
| | | | | | | | | | | | | | Task name contain expresion (eg, do_foo_remove_bar) can cause fatal error. Check for naming before addtask. Prompt with understandable error message when expression found in task name. [YOCTO #8805] (Bitbake rev: 5b4a5bb0960386f9c524c220e43a16e60e38964d) Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build: Allow deltask to take multiple tasknamesRichard Purdie2020-07-211-4/+1
| | | | | | | | | | | | | | | | | | | deltask currently supports only one task to delete but it would be useful if it could support a variable which gets expanded to allow flexibility in the metadata. This is simple to support in bitbake and is how other directives such as inherit operate so adjust the parser/code to handle that. It means that syntax like: EXTRA_NOPACKAGE_DELTASKS = "" deltask ${EXTRA_NOPACKAGE_DELTASKS} is now allowed. (Bitbake rev: 883d926120833c85a16dcf60425dd7af7699046a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: remove unused importsFrazer Clews2020-01-191-2/+0
| | | | | | | | | | removed unused imports which made the code harder to read, and slightly but less efficient (Bitbake rev: 4367692a932ac135c5aa4f9f2a4e4f0150f76697) Signed-off-by: Frazer Clews <frazer.clews@codethink.co.uk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: lib: Cleanup /usr/bin/env pythonRobert Yang2019-06-281-1/+0
| | | | | | | (Bitbake rev: cc712f3257904960247a7532cfc4611f3dccd36c) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> 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: BBHandler: Fix addtask and deltaskRobert Yang2019-04-301-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The following commands are not supported, but they were ignored silently, that may suprise users: * addtask task1 task2 task2 is ignored * addtask task1 before task2 before task3 Should be: addtask task1 before task2 task3 * addtask task1 after task2 after task3 Should be: addtask task1 after task2 task3 * deltask task1 task2 task2 is ignore This patch can check and warn for them. [YOCTO #13282] (Bitbake rev: 675689aa7cc7287efecf8ef775ca2059369167f1) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Fix Deprecated warnings from regexsRichard Purdie2019-01-161-9/+9
| | | | | | | | | Fix handling of escape characters in regexs and hence fix python Deprecation warnings which will be problematic in python 3.8. (Bitbake rev: c1fcc46e2498ddd41425d8756754f814d682aba3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: BBHandler: Check tab indentation for python codeRobert Yang2018-12-051-0/+11
| | | | | | | | | | | | | | | | | | 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: BBHandler: Fix __python_func_regexp__ for comment linesRobert Yang2018-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed: - Add a comment in base.bbclass: def oe_import(d): import sys # Comment bbpath = d.getVar("BBPATH").split(":") [snip] Note, '# Comment' is started with '#', it is legal in python's syntax (though maybe not a good style), but bitbake reported errors: $ bitbake -p ERROR: ParseError at /path/to/base.bbclass:20: unparsed line: ' bbpath = d.getVar("BBPATH").split(":")' This error report would mislead people, the real problem is that '# Comment' is not supported, but it reports the next line, this may make it hard to debug the code are complicated. We can make __python_func_regexp__ handle '^#' to fix the problem, since it already can handle blank line "^$" in a python function, so it would be pretty safe to handle "^#" as well. (Bitbake rev: 79e62eef1c93f742bf71e9f25db57fdd2ffedd02) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: parse: fixes for resolve_file()Robert Yang2018-02-141-3/+0
| | | | | | | | | | The resolve_file() calls mark_dependency(), so the one which calls resolve_file() doesn't need call mark_dependency() again. (Bitbake rev: 4682571107323a39b42cd9ec8ee67419e7f15acc) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Remove old style bb.data.setVar() syntax usageEnrico Scholz2017-07-081-1/+1
| | | | | | | | | | | | | | Fixes except bb.parse.SkipRecipe: > bb.data.setVar("__SKIPPED", True, d) if include == 0: AttributeError: module 'bb.data' has no attribute 'setVar' (Bitbake rev: d43e97226dc7f53592c06a528f20390b68dc854f) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: use with instead of open/close2.3_M1Ross Burton2016-12-161-11/+11
| | | | | | | | | | This is more pythonic and can handle unclosed file warnings better than the previous code structure. (Bitbake rev: 50633012a64a3b5f0662145e29ff426374fb7683) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: remove True option to getVar callsJoshua Lock2016-11-301-1/+1
| | | | | | | | | | | | 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: bitbake: Drop futures usage since we're python 3Richard Purdie2016-06-021-1/+1
| | | | | | (Bitbake rev: bf25f05ce4db11466e62f134f9a6916f886a93d9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/ast: Merge handMethod and handleMethodFlagsRichard Purdie2016-02-101-3/+2
| | | | | | | | | | The functionality overlap between these two functions is significant and its clearer to handle both things together since they are intimately linked. There should be no behaviour change, just clearer code. (Bitbake rev: 391aa4afc91be90d8d3ee47e1bf797d6ebe61a71) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Improve IN_PYTHON_EOF handlingRichard Purdie2015-12-221-14/+4
| | | | | | | | | | | | | | | | Now we're actively using the line numbers for other thins, having magic values like IN_PYTHON_EOF causes problems, in particular, 32 bit overflow on 32 bit machines. There is a neater way to signal eof to feeder(), just using an extra parameter so use this instead and drop the IN_PYTHON_EOF magic values. This has the added bonus that line numbers are then correct for python functions at the end of files. (Bitbake rev: e0f05871c2a6f1e86ae19ad343c7c6f822ddb67e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add explict getVar param for (non) expansionRichard Purdie2015-06-231-4/+4
| | | | | | | | | | | | | | 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: parse/BBHandler: Avoid repeatedly resetting FILERichard Purdie2015-06-051-2/+2
| | | | | | | | | | | | If we're not going to change the value of FILE, or we know it isn't going to have changed (ext == bbclass), don't set FILE. This avoids messy looking history of the variable as well as optimises parsing speed slightly. (Bitbake rev: 88e4600aa66dda2e6c807f9d97af8982bcd8817b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Drop cwd from search pathRichard Purdie2015-05-291-2/+1
| | | | | | | | | | | | | | | | Whilst bitbake has done this for a long time, the behaviour of resolving class files against cwd is not desirable. This can be seen during base configuration parsing when looking for base.bbclass where a dependency on cwd is added. If cwd then changes, the cache is invalid and triggers a re-parse. The only real option is to drop this entry and if files can't be found, we fix BBPATH in the cases where it needs fixing. I didn't find any in the random selection of layers I tested parsing locally. (Bitbake rev: 508aad9d5db7e51328b1fd6ee53b4bc3720a30b7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Error for incomplete function definitionsRichard Purdie2015-05-151-7/+12
| | | | | | | | | | | | | | | | | | | | | Add some sanity checks on the parsing state engine when returning data so that incomplete functions raise parse errors. This means a recipe doing: do_somefunction { echo 1 VAR = "1" will now raise a ParseError. To get the right file/line information, __infunc__ was changed to a list. [YOCTO #7633] (Bitbake rev: 6b54a72638f57882d4fd5aab96b2752a09e065af) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: Add SkipRecipe event to replace SkipPackageRichard Purdie2014-06-011-1/+1
| | | | | | | | | | | | In the depths of time we were rather confused about naming. bb files are recipes, the event to skip parsing them should be SkipRecipe, not SkipPackage. This changes bitbake to use the better name but leaves the other around for now. We can therefore start removing references to it from the metadata. (Bitbake rev: 98d9e6e0f514a7cb7da1d99bf4bd5602b89426d6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Improve file inheritance loggingRichard Purdie2014-05-111-7/+1
| | | | | | | | | | | | | | | The file inheritance logging has been here since the dawn of time. It duplicates output many times over and logs to debug level 2. When running with the debug option, its understandable the user may want to see the paths of files included in the build. These changes remove pointless/duplicate output and print the include paths clearly at debug level one in a form which users should be able to more easily parse. (Bitbake rev: 633a56987df639295fe9128418da5634050063e5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ast/BBHandler/build: Add support for removing tasks (deltask)Richard Purdie2013-12-181-0/+6
| | | | | | | | | | | | | | | | | Back in the depths of time we did support task removal. In the pre AST days it was nearly impossible to continue supporting it, it wasn't used so it was dropped. With the modern codebase we can easily now support deltask and it would be very useful within the metadata since it can massively simplify dependency trees. As an example, a core-image-sato had 47703 inter task dependencies before this patch and a patch to native.bbclass, afterwards with the noexec tasks deleted, we had 29883. Such a significant simplification is worthwhile and justifies adding a deltask operation to the system. (Bitbake rev: acecbde6fb70ff3c96deab3cdf819d8442e87ed4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse/ConfHander/BBHandler/utils: Fix cache dependency bugsRichard Purdie2013-11-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently bitbake only adds files to its dependency list if they exist. If you add 'include foo.inc' to your recipe and the file doesn't exist, then later you add the file, the cache will not be invalidated. This leads to another bug which is that if files don't exist and then you add them and they should be found first due to BBPATH, again the cache won't invalidate. This patch adds in tracking of files we check for the existence of so that if they are added later, the cache correctly invalidates. This necessitated a new version of bb.utils.which which returns a list of files tested for. The patch also adds in checks for duplicate file includes and for now prints a warning about this. That will likely become a fatal error at some point since its never usually desired to include a file twice. The same issue is also fixed for class inheritance. Now when a class is added which would be found in the usual search path, it will cause the cache to be invalidated. Unfortunately this is old code in bitbake and the patch isn't the neatest since we have to work within that framework. [YOCTO #5611] [YOCTO #4425] (Bitbake rev: 78d285871e4b8c54ccc4602d571e85f922e37ccd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: methodpool: Retire it, remove global method scopeRichard Purdie2013-05-241-4/+0
| | | | | | | | | | | | | | | | | Having a global method scope confuses users and with the introduction of parallel parsing, its not even possible to correctly detect conflicting functions. Rather than try and fix that, its simpler to retire the global method scope and restrict functions to those locations they're defined within. This is more what users actually expect too. If we remove the global function scope, the need for methodpool is reduced to the point we may as well retire it. There is some small loss of caching of parsed functions but timing measurements so the impact to be neglibile in the overall parsing time. (Bitbake rev: 4d50690489ee8dc329a9b0c7bc4ceb29b71e95e9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: Clean up various file access syntaxRichard Purdie2013-05-091-0/+1
| | | | | | | | | | | | | Python 3 is stricter about how files are accessed. Specficially: * Use open(), not file() * Use binary mode for binary files (when checksumming) * Use with statements to ensure files get closed * Add missing file close statements (Bitbake rev: 9f08b901375ba640f47596f1bcf43f98a931550f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/ConfHandler: Merge fix for multiline commentsRichard Purdie2013-01-211-1/+1
| | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: BBHandler/ConfHandler: Improve multiline comment handlingRichard Purdie2013-01-211-1/+4
| | | | | | | | | | | | | | | | | | | | 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 <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_smart/BBHandler: Fix SkipParse exception handlingRichard Purdie2012-12-141-1/+6
| | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: BBhandler/data: Fix __inherit_cache duplicationRichard Purdie2012-12-111-0/+7
| | | | | | | | | | | | 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: BBHandler/ast: Simplify/fix EXPORT_FUNCTIONS usageRichard Purdie2012-12-111-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: Revert "BBHandler: Ensure parser state engine is correctly reset ↵Richard Purdie2012-12-071-3/+2
| | | | | | | | for new parsing" This reverts commit 3dc5e896a97154914cee6c47900e3bb2a2627cdb. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler: Ensure parser state engine is correctly reset for new ↵Richard Purdie2012-12-071-2/+3
| | | | | | | | | | | parsing 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 <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-05-21 21:47:51 +0000