summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/cookerdata.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: cookerdata: Be consistent with what type bb_data representsPeter Kjellerstedt2023-11-231-6/+5
| | | | | | | | | | | | | | | | In _parse_recipe(), bb_data was initially a datastore object, but then after the call to bb.parse.handle() it was all of a sudden turned into a dict of variant:datastore pairs. At the same time, parseRecipeVariants() used bb_data for datastore objects, while parseRecipe() used it for the dicts of variant:datastore pairs. Change these functions to consistently use "bb_data" for datastore objects and use "datastores" for the dicts of variant:datastore pairs. (Bitbake rev: ed0f94c037476efd465db87726b2480406076beb) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add FILE_LAYERNAME variable containing the layername for a ↵Richard Purdie2023-05-251-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | recipe There are times when it would be useful for code to know which layer (or collection in old bitbake terms) it is contained within. Add support for FILE_LAYERNAME to be set by bitbake when parsing a recipe so that it is possible to determine this. To do it, we need to pass data from the cooker into the recipe endpoints, since only the top level cooker information knows about the layer structure which makes the patch a bit painful. The idea is that this would make layer overrides possible: OVERRIDES .= ":layer-${FILE_LAYERNAME}" which then opens possibilities like: WARN_QA:append:layer-core = " patch-fuzz" as an example where OE-Core could enable specific QA tests only for that specific layer. (Bitbake rev: 7090a14b0035842112d073acf7f2ed1a01fdeccf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Drop dubious exception handling codeRichard Purdie2023-02-191-5/+0
| | | | | | | | | | | This code appears to be dangerous, it swallows exceptions, turning them into "handled" versions which then show no errors to the user. This is a pretty poor user experience and I can't see why this code should be swallowing such things. Drop the worst bits of code. (Bitbake rev: 13279044f16f2cf2502ebf39d277415f99bb6c18) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Improve early exception handlingRichard Purdie2023-02-191-9/+1
| | | | | | | | | | | | | | | | Martin Jansa reported that if you put a syntax error into an imported module such as qa.py in OE, no error is shown. Part of the issue appears to be that the catch_parse_error() decorator only catches certain exceptions and SyntaxError isn't one of them. As far as I can tell we should remove all the special cases and use the more advanced code in all cases, not just expansion errors. I confirmed this now prints a proper error message for a qa.py syntax error. (Bitbake rev: 2365d891847f8e73d1c4661ddfdab8818ff619dc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Remove incorrect SystemExit usageRichard Purdie2023-02-171-1/+1
| | | | | | | | | | | Calling SystemExit doesn't work well with server/client usage since the string isn't printed to the right place. Use bb.fatal() instead which prints the right log output and raises and handled exception which then shows correctly on the UI. (Bitbake rev: aaefb43b41a0d9b16a59643136268eb6e5d48cd2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache/codeparser: Switch to a new BB_CACHEDIR variable for cache ↵Richard Purdie2023-01-261-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | location Currently the codeparser cache is set from CACHE, which is typically in bitbake.conf which means we can't read/write any cache until it is found/read. We may well have python expressions to parse before that happens. The net result is suboptimal functioning of the codeparser cache since it will often be invalidated by data that is never written. This patch changes the codeparser and filechecksum caches to use BB_CACHE as their setting and defaults it to ${TOPDIR}/cache. The patch doesn't change where the "persistent" data such as prserver and hash-equiavalance resides (PERSISTENT_DIR) or where the metadata parsing cache resists (still currently CACHE). I've left those for a later patch. The patch does ensure data parsed by the core datastore parsing calls is written back since this is now much more useful after this change. (Bitbake rev: ee89ade5b5a4cf9c53f336d8b800e06fbe436628) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix previous commit to use a string, not a generatorRichard Purdie2023-01-021-1/+1
| | | | | | | | | | The previous commit was injecting a generator object instead of a string, which happened to fix the issue but we should fix it properly! Thanks to Christopher Larson for spotting. (Bitbake rev: 36589f13c5babb3b2af82666c8a96338e6ea4eb9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix cache/reparsing issueRichard Purdie2023-01-011-2/+2
| | | | | | | | | | When setting the LAYERSERIES_COMPAT and LAYERSERIES_CORENAMES variables, we need to be deterministic. The random ordering from the sets was causing unexpected reparses. (Bitbake rev: 8c405c97430ac830837e25438e8795f6f7abbdaa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata: Rework the way the datastores are resetRichard Purdie2022-12-311-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | As far as I could tell, the current code could result in some strange situations where some data was set back to the original data store copy but the multiconfig data was not restored. There are also some changes made to the datastore which did not persist. The data store was also being reset at every client reset, which seems a little excessive if we can reset it to the original condition properly. Move the __depends -> __base_depends rename into databuilder along with the __bbclasstype change so these are saved in the original data. Tweak the databuilder code to be clearer and easier to follow on which copies are where, then save copies of all the mc datastores. Finally, drop the cache invalidation upon reset for the base config as we shouldn't need that now (oe-selftest -r tinfoil works with memory resident bitbake which was the original reproducer requiring that change). (Bitbake rev: 5f8b9b9c35b4ec0c8c539bf54ca85f068f4a5094) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: codeparser/data: Add vardepsexclude support to module dependency codeRichard Purdie2022-12-171-0/+1
| | | | | | | | | | | We need to be able to exclude dependencies from the python module dependency code. Add support for the vardepexclude flag for these. It only works from the configuration namespace rather than per recipe for efficiency. (Bitbake rev: 1aa672b01037fda4ca82f2c7e394783287c09ecd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Ensure layers use LAYERSERIES_COMPAT fairlyRichard Purdie2022-12-081-2/+27
| | | | | | | | | | | | | | Some layers think they're going to be 'clever' and copy the values from another layer, e.g. using ${LAYERSERIES_COMPAT_core}. The whole point of this mechanism is to make it clear which releases a layer supports and show when a layer master branch is bitrotting and is unmaintained. Therefore add some code to avoid people doing this. I wish we didn't have to but... (Bitbake rev: 6709aedccbb2e7ddbb1b2e7e4893481a7b536436) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Add support for addpylib conf file directive and ↵Richard Purdie2022-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: cache/cookerdata: Move recipe parsing functions from cache to ↵Richard Purdie2022-11-201-0/+51
| | | | | | | | | | | | | | | databuilder When 'NoCache' was written, databuilder/cookerdata didn't exist. It does now and the recipe parsing functionality contained in NoCache clearly belongs there, it isn't a cache function. Move those functions, renaming to match the style in databuilder but otherwise not changing functionality for now. Fix up the callers to match (which make it clear this is the right move). (Bitbake rev: 783879319c6a4cf3639fcbf763b964e42f602eca) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Fix a few more logger debug() callsJoshua Watt2022-09-211-2/+2
| | | | | | | | | | | f68682a7 ("logging: Make bitbake logger compatible with python logger") replaced several .debug() calls to make them comply with the standard python logging API, but a few were missed. (Bitbake rev: eb25cd4d64b9a4e8e2b2ce7fbccc123d00b2fc2b) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: BBHandler/cooker: Implement recipe and global classesRichard Purdie2022-08-121-0/+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: cookerdata: Change emphasis in error message to be clearer to usersRichard Purdie2022-05-051-1/+1
| | | | | | | | | Users are misreading this message. Reorder the wording to make the empahsis clearer on the shell environment. (Bitbake rev: dd2475e36af470ea47b0841d181444e36aa6e947) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Replace "abort" usage in task handlingScott Murray2022-02-211-2/+2
| | | | | | | | | | | | | | In line with the inclusive language migration defined at: https://wiki.yoctoproject.org/wiki/Inclusive_language replace the use of "abort" with "halt" in code related to handling task failure. (Bitbake rev: 831fb7f2329a3cd95b71e9c85d7d7f0d717f947f) Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Add support to BB_RENAMED_VARIABLES for custom stringsRichard Purdie2022-02-211-2/+4
| | | | | | | | | Add support for custom strings in BB_RENAMED_VARIABLES and use this to show that BB_STAMP_WHITELIST and BB_STAMP_POLICY are no longer supported. (Bitbake rev: 0914011f7647571ab125bbddcd7d68e3da47226a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart/cookerdata: Add variable remapping supportRichard Purdie2022-02-211-0/+21
| | | | | | | | | | | | | | | | | | | | This change adds support for improving the user experience when variables are renamed. This isn't as simple as it might first appear since some bitbake variables are used through the environment before the datastore exists, some are bitbake variables which we know about straight away and some are metadata defined which we don't know about until later. This patch adds support for handling these different cases, allowing a list of bitbake renamed variables to be defined in bitbake itself and allows this to be extended through the metadata using BB_RENAMED_VARIABLES. In order to give the best feedback to the user, we default to turning on variable history tracking in the base data store from knotty, which allows filename and line number information to be shown. (Bitbake rev: bd50a5d5e4b4fa90844464396887ebdff0d4e5f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix typo "normally"Zygmunt Krynicki2022-02-201-1/+1
| | | | | | | (Bitbake rev: d0b633256daf8d11f213a14fb44ebc6bc5d45f37) Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/cooker: Fix source revision handling with floating upstreamsRichard Purdie2022-02-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Where a git url uses a tag instead of a full source revision, breakage can currently occur in builds. Issues include: * the revision being looked up in multiple tasks (fetch and unpack) * the risk a different revision may be obtained in those tasks * that some tasks may not be allowed to access the network * that a revision may not be consistent throughout a given build * rerunning a specific task may given inconsistent results To fix this, stop the workers from cleaning out the source revision store. This should only be done in the cooker itself (based on current policy). Also, where the code "sees" an upstream access, mark the recipe as not to be cached. The reparse re-triggers the upstream lookup by the server. Add a test to ensure that if get_srcrev isn't called, the user is told they're using a configuration that is known to break. (Bitbake rev: 4b5eed1626709ef3dc06b32fd55d40a2a6edd179) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Set TOPDIR explicitly and fix broken findTopdir()Richard Purdie2021-11-151-6/+6
| | | | | | | | | | | | | | | | | | TOPDIR is set internally deep within the parser to os.getcwd(). Rather than do that, set it explicitly if not set. Note that modern code will almost always have a bblayers.conf file which would have already set TOPDIR before this new code. Also fix findTopdir since the conf/bitbake.conf codepath is just plain incorrect, it would find build metadata, not the current build directory that bitbake would use. Again, the use of bblayers.conf means hitting the fallback code was unlikely. This change makes everything clear and explicit. (Bitbake rev: c03df5283408dfd089b6317677d2b7af6fa73936) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Clean up use of len()Richard Purdie2021-11-031-1/+1
| | | | | | (Bitbake rev: bbbc843e86639604d00d76b1949b94a78cf1d95d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Show a readable error for invalid multiconfig nameRichard Purdie2021-09-191-0/+2
| | | | | | | | | | | | | | If a multiconfig starts with a digit, users would see pages of errors as we use the multiconfig as a python function name prefix and python functions cannot start with a digit. We could avoid doing that but it is easier just to ask users to name multiconfigs not starting with digits. This tweak ensures the user sees an easier to understand error. (Bitbake rev: f9cddaeef35b2ea0dadf717101ed896f6b857abd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Show error for no BBLAYERS in bblayers.confRichard Purdie2021-09-111-0/+3
| | | | | | | | | | | If there is no BBLAYERS set in bblayers.conf show a more helpful error and exit. [YOCTO #14340] (Bitbake rev: 97183e10faf9862b5d9489d6e2c27ac77c3b697d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Improve missing core layer error messageRichard Purdie2021-09-111-0/+2
| | | | | | | | | | | If the core layer is missing from bblayers.conf, the message the user sees is hard to understand. Improve it. [YOCTO #14340] (Bitbake rev: 5815a7258ebb8a989e0c6f5798853559d9413f02) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: Prevent bitbake from executing event handler for wrong ↵Tomasz Dziendzielski2021-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | multiconfig target When multiconfig is used bitbake might try to run events that don't exist for specific mc target. In cooker.py we pass `self.databuilder.mcdata[mc]` data that contains names of events' handlers per mc target, but fire_class_handlers uses global _handlers variable that is created during parsing of all the targets. This leads to a problem where bitbake runs event handler that don't exist for a target or even overrides them - if multiple targets use event handler with the same name but different code then only one version will be executed for all targets. See [YOCTO #13071] for detailed bug information. Add mc target name as a prefix to event handler name so there won't be two different handlers with the same name. Add internal __BBHANDLERS_MC variable to have the handlers lists per machine. (Bitbake rev: 5f7fdf7b2d8c59805c8ef4dae84f536baa5e172b) Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: tweak to avoid mutable default argumentChris Laplante2020-11-111-3/+3
| | | | | | | (Bitbake rev: 36ee858415866a122784b05f06e2af0c92dfcafd) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix exception raise statementsRichard Purdie2020-09-051-3/+3
| | | | | | | | Lets use valid python even if it the original happens to work. (Bitbake rev: 343187c57e1459b0e57f90463843782f3a3a8443) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata: Use BBHandledException, not sys.exit()Richard Purdie2020-09-051-5/+5
| | | | | | | | | | | | | | | Calling sys.exit() in the middle of the code is rather antisocial. We catch this in various places but we shouldn't have to. In all these cases we have already sent events explaining to the user what happened. This means the correct exception is BBHandledException. The recent startup changes have moved the point a lot of this code gets called to inside the UI, with memres it would have always been possible from there anyway. This change makes things much more consistent. (Bitbake rev: 91699f366d24480ff3b19faec78fb9f3181b3e14) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main/server/process: Drop configuration object passingRichard Purdie2020-08-251-9/+0
| | | | | | | | | | | | | | | | | | | The first thing the UIs do is update the server config from the UI. We can just rely upon that and start the server with a standard config, removing the need to pass the confusing configuration object around as well as configParams, which contains a similar copy of some of the data. This makes memory resident bitbake work the same way as the normal mode, removing the opportunity for some class of bugs. The xmlrpcinterface and server_timeout values are passed in at server startup time now and there no longer a second option in the configuration which is effective ignored once the server starts. (Bitbake rev: 783a03330802e83c525c55522e3ee2a933bded3a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata: Ensure UI event log is updated from commandlineRichard Purdie2020-08-251-1/+1
| | | | | | | | | Currently the eventlog is not handled correctly for memory resident bitbake. Fix this by allowing adpations to configuration changes. (Bitbake rev: f7d2c9116116659ea42260a3bb96dca100aadae7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Ensure UI options are updated to the serverRichard Purdie2020-08-251-1/+3
| | | | | | | | | | | | There were some options which were not being passed to the server. This was breaking, particularly in memory resident bitbake mode. Add the missing options to the correct place to ensure the server is updated correctly. (Bitbake rev: 5dc178e7fae3ca8558146e385a05f5d96a021777) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata/main: Improve loglevel handlingRichard Purdie2020-08-251-4/+6
| | | | | | | | | | | Rather than passing debug/verbose/debug_domains around, pass the computed output of these. Ensure that the cooker sets the levels to match the levels currently set in the UI and generally try and make it easier to understand what the code is doing. (Bitbake rev: f0535beecc692a6213be2a22f9eef5956450ecf8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/msg: Cleanup verbose option handlingRichard Purdie2020-08-251-1/+6
| | | | | | | | | | | | The levels of indirection to set these verbose logging options is rather crazy. This attempts to turn things into two specific options with much more specific meanings. For now its all still controlled by the commandline verbose option and should funciton as previously, with the addition that the BB_VERBOSE_LOGS option can now be task specific. (Bitbake rev: 423c046f2173aaff3072dc3d0882d01b8a0b0212) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Simplfy idle callback handler functionRichard Purdie2020-08-131-7/+1
| | | | | | | | | | Having the idle callbacks abstracted via the configuration object makes no sense. Its like this for historical reasons from the multiple server backends but we don't need this now so simplfy. (Bitbake rev: e56c49717355c9493b07d5fc80981a95ad8a0ec8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Add BBFILES_DYNAMIC inverse modeKonrad Weihmann2020-06-231-2/+5
| | | | | | | | | | | | Add an inverse mode for BBFILES_DYNAMIC. Entries where the layername is prefix with '!' will act in inverted mode including given glob mask in absence of the referenced layer. This is useful to backfill recipes from potentially missing layer. (Bitbake rev: bfd729cfe06351ccd0071004e23af1d04546c723) Signed-off-by: Konrad Weihmann <kweihmann@outlook.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Add mc conffiles hashes to cache hashJoshua Watt2019-09-271-1/+5
| | | | | | | | | | | | | | | | | | | | | The variable values that result from parsing multiconfig should be included in the cooker data hash, otherwise changes to these files won't be detected, which will allow the parsing cache to be loaded with the old values for the multiconfigs. This can either manifest as the variable values simply not updating, or getting basehash changed errors when building. This bug was previously undetected because all of the multiconfig base files were a direct file dependency in all parsed recipes. This was fixed in 34137a00f60 ("bitbake: bitbake: cooker: Rename __depends in all multiconfigs"), exposing this bug. [YOCTO #13541] (Bitbake rev: c74481aa15226e1bff9d53e4ee4b702ebfa1ad32) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Delay the setup of the siggen slightly to allow ↵Richard Purdie2019-08-211-1/+1
| | | | | | | | | | | | metadata defined siggens If we define a metadata siggen it can fail due to the early init here. Move slightly later to avoid those failures which allows fixes in OE to the check-layer script related to the hash equiv siggen. (Bitbake rev: fdf5c341f3393173876a753c46c9bd067eb2b353) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add --skip-setscene optionJoshua Watt2019-07-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds an option to skip _setscene only if they would normally be executed, without ignoring sstate completely. Previously, '--no-setscene' would allow a build that completely ignored sstate and _setscene tasks, and '--setscene-only' would allow a build that only ran _setscene tasks, but there was no option do a build that would respect tasks previously restored from sstate and build everything else. Now one can run: bitbake --setscene-only IMAGE; bitbake --skip-setscene IMAGE which is functionally equivalent to: bitbake IMAGE The indented use is to allow a build to complete successfully in the presence of _setscene task failures by splitting apart the two phases e.g.: (bitbake -k --setscene-only IMAGE || true) && bitbake --skip-setscene IMAGE (Bitbake rev: 813ba5b7c13b573a0b813b628a819bdbf0627540) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> 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: cooker: list all nonexistent bblayer directoriesOleksandr Kravchuk2019-06-181-3/+13
| | | | | | | | | | | | | Check existence of all the bblayer direcotories at once and print them all, so if there are multiple nonexistent directories, user does not have to correct bblayers.conf and restart bitbake multiple times. [YOCTO #11647] (Bitbake rev: 19291f7c4d17086ebb6a7b80c3cb06333d7fd55b) Signed-off-by: Oleksandr Kravchuk <open.source@oleksandr-kravchuk.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-12/+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: bitbake: cookerdata: Check duplicated BBFILE_COLLECTIONSRobert Yang2019-02-141-0/+4
| | | | | | | | | It shouldn't work when there are duplicated BBFILE_COLLECTIONS. (Bitbake rev: a1f251e5ab859d6d4a2cb908408d4ddcab5a5de1) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Issue warning if layer doesn't set LAYERSERIES_COMPAT_xRichard Purdie2018-04-061-0/+2
| | | | | | | | | | | We'd like layers to set this variable so that we know which layers are compatible with which others, even if the branch is a generic un-updated "master" branch. Start printing a warning to highlight this issue. (Bitbake rev: cca81e33b58c390dcf5cc3a31555a43b79177166) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main/runqueue: Rework runall task and add runonly optionRichard Purdie2018-02-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The runall commandline option was confusing people. There are in fact two different behaviours people may want. a) For a given target (or set of targets) look through the task graph and run task X only if its present and would have been built. b) For a given target (or set of targets) look through the task graph and run task X if any recipe in the taskgraph has such a target even if it wasn't in the original task graph. I've decided to interpret the existing "runall" option as b), even if right now if behaves like a). For a), which is a valid use case, this patch adds a "runonly" option. With both behaviours present, I'm hoping we can then kill off the "fetchall", "checkuriall" and other tasks from OE metadata and replace them with this option. This would significantly speed up task graph processing. (Deleting the checkuriall and fetchall tasks takes "bitbake core-image-sato -g" from 22s to 8s). (Bitbake rev: 546a662c877b2d3af35e3996950582ed2df41fe4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata/taskdata/runqueue: Drop remaining tryaltconfigs code and ↵Richard Purdie2017-09-021-1/+1
| | | | | | | | | | | | | commandline option I can't actually see how this was working, nothing connected the commandline option to the data in TaskData(). Drop the remaining pieces of this option, it was a relic from a decade ago and we want deterministic builds, not random tries until something might work. (Bitbake rev: 767c7ba8fc76ec667ac1567de1c971c3575f2ecd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Avoid tracebacks from early reset() callsRichard Purdie2017-08-311-0/+3
| | | | | | | | | cooker.reset() can be called before we've actually setup the datastore. Gracefully handle this case instead of the current traceback+exit. (Bitbake rev: 8fd30ca6d271c125a8ea03ef0c5d7ab176900701) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-07-19 10:44:23 +0000