summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/cookerdata.py
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* bitbake: cooker: Change to consistent prefile/postfile handlingRichard Purdie2017-08-311-2/+0
| | | | | | | | | | | | | | Currently the original prefile and postfile passed when starting bitbake server are 'sticky'. With the new memory resident model this doesn't make sense as the server the system is started with isn't special. This patch changes the code so the prefile/postfile are used if specified on the commandline and not used otherwise. This makes the behaviour much more predictable and expected and as an added bonus simplifies the code. (Bitbake rev: 638d366234fad78f283d3a13a12b07cb0ccbe914) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Handle datastore tracking for showEnvironment server side onlyRichard Purdie2017-08-311-6/+1
| | | | | | | | | | The current passing of "tracking" backwards and forwards, client to server is ugly and complex and error prone. Instead, set this during showEnvironment commands triggering a reset there if/as required. (Bitbake rev: 9dc7f384db0479569ff93a76a623d5395fecaf47) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata/cooker: Restore original datastore upon client disconnectRichard Purdie2017-07-211-0/+9
| | | | | | (Bitbake rev: 67ae612ab890965357d24a9bd35610cf813b79ba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server: Rework the server API so process and xmlrpc servers coexistRichard Purdie2017-07-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the way bitbake server works quite radically. Now, the server is always a process based server with the option of starting an XMLRPC listener on a specific inferface/port. Behind the scenes this is done with a "bitbake.sock" file alongside the bitbake.lock file. If we can obtain the lock, we know we need to start a server. The server always listens on the socket and UIs can then connect to this. UIs connect by sending a set of three file descriptors over the domain socket, one for sending commands, one for receiving command results and the other for receiving events. These changes meant we can throw away all the horrid server abstraction code, the plugable transport option to bitbake and the code becomes much more readable and debuggable. It also likely removes a ton of ways you could hang the UI/cooker in weird ways due to all the race conditions that existed with previous processes. Changes: * The foreground option for bitbake-server was dropped. Just tail the log if you really want this, the codepaths were complicated enough without adding one for this. * BBSERVER="autodetect" was dropped. The server will autostart and autoconnect in process mode. You have to specify an xmlrpc server address since that can't be autodetected. I can't see a use case for autodetect now. * The transport/servetype option to bitbake was dropped. * A BB_SERVER_TIMEOUT variable is added which allows the server to stay resident for a period of time after the last client disconnects before unloading. This is used if the -T/--idle-timeout option is not passed to bitbake. This change is invasive and may well introduce new issues however I believe the codebase is in a much better position for further development and debugging. (Bitbake rev: 72a3dbe13a23588e24c0baca6d58c35cdeba3f63) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Add a function to find TOPDIRRichard Purdie2017-07-211-0/+21
| | | | | | | | | | | | Finding the top level build directory is currently hard and relies on having a complete cooker being setup. Add a helper function which does the same thing without all the extra overhead. This is needed to be able to locate the bitbake lockfile and hence the socket for connecting clients in the new server model. (Bitbake rev: d196afe68032898c31a8599ca7d3ceba58d96b0a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: fix indentation and trailing spacesPaul Eggleton2017-07-181-5/+5
| | | | | | | | | Fix one incorrect indentation and several lines with trailing spaces. (Bitbake rev: 4dbf4f1907a32f303c2e9acf2f27817cf3c9ec38) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add MultiConfigParsed eventRichard Purdie2017-07-081-0/+2
| | | | | | | | | | There are some cases where the metadata needs to be aware a multiconfig build is happening and have access to the multiconfig data stores to merge data into the common build. This adds such an event allowing access to these datastores. (Bitbake rev: 160e47f5df90850e64dcb857c81a5039abc9235f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Implement LAYERSERIES_COMPAT and LAYERSERIES_CORENAMESRichard Purdie2017-06-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, someone trying a master branch of any given layer may or may not find it works with the version of OE-Core that they have picked. This patchset introduces LAYERSERIES_CORENAMES and LAYERSERIES_COMPAT_<layername> with the intention of allowing layers to indicate which versions of the core project they're compatible with. In general the master branch will use the next release codename as the value of LAYERSERIES_CORENAMES, meaning that the waterfall model of layer releases is supported with layers updating their LAYERSERIES_COMPAT_ values as they branch for release. Both variables support multiple strings and a given layer is accepted if there is overlap of any one value. This means a layer can be compatible with multiple core versions. Setting LAYERSERIES_COMPAT_ will be required by the Yocto Project Compatible v2 standard but the system will not error if its not set at this point. This should make it clear when a given layer is unmaintained and untested with new releaes of OE-Core, a common user pain point. (Bitbake rev: 92c49b9b1a16dfd35444db8143bd4cae4cda70cc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: add BB_CMDLINE to enable access to UI command line with memresPaul Eggleton2017-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | In OpenEmbedded's buildhistory class we want access to the bitbake command line that launched the build, and up to now we were simply using sys.argv from within the event handler to get that. Unfortunately that doesn't work in memory resident mode, since the event handler is naturally executing within the server and thus will give you the command that launched the bitbake server which is much less interesting. Add a dynamic variable BB_CMDLINE to provide access to this, set from sys.argv within the UI process in updateToServer(). (Note that BB_CMDLINE isn't currently passed through to the worker, so this is only really readable from event handlers plus any explicit getVariable calls - in theory an observe-only UI could read it for example.) Part of the fix for [YOCTO #11634]. (Bitbake rev: 8ad31a3eff5cfcb7b1c462578a582dafcbc426d4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: fix variable history not showing in bitbake -e with memresPaul Eggleton2017-06-121-1/+1
| | | | | | | | | | | | | | | | | | CookerConfiguration sets the "tracking" option to True when -e is specified in order to have history tracking enabled in the datastore so that we can show variable history (which isn't enabled by default for performance reasons), however in memory resident mode this wasn't doing anything because it was happening on the UI side only. We do have a mechanism for updating the cooker configuration in the server, but the tracking option wasn't being included in the list of options we updated, so we just need to add this option to fix the issue. Fixes [YOCTO #10730]. (Bitbake rev: 57d4977555cf892b15dd0302dfe261fe37d49327) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Add support for BBFILES_DYNAMICPatrick Ohly2017-06-091-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BBFILES_DYNAMIC can be used to activate content only when some other layers are present. The other layers are identified by the collections that they define. The main use case is to avoid .bbappends without the corresponding .bb file in layers that want to modify other layers via .bbappends without introducing a hard dependency on those other layers. .bb files could also be handled via BBFILES_DYNAMIC. Entries in BBFILES_DYNAMIC must have the form <collection name>:<filename pattern>. Example usage: BBFILES_DYNAMIC += " \ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ " Parsing is aborted when invalid entries are found with an error message like this: ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not: /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend Based on a patch by Richard Purdie. (Bitbake rev: 04f8bd50aa04b12cf91dd6a3154527ad2c24695c) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: add option to run all tasks in specific build targetMatthew McClintock2017-03-131-0/+1
| | | | | | | | | | | | | | | | | | | | For example: $ bitbake core-image-minimal --runall unpack ... NOTE: Tasks Summary: Attempted 326 tasks of which 88 didn't need to be rerun and all succeeded. $ bitbake core-image-minimal --runall patch NOTE: Tasks Summary: Attempted 453 tasks of which 332 didn't need to be rerun and all succeeded. This can replace fetchall as well: $ bitbake core-image-minimal --runall fetch NOTE: Tasks Summary: Attempted 135 tasks of which 119 didn't need to be rerun and all succeeded. (Bitbake rev: 7c0fa6ba66cdb956b37d94055307cde857633df9) Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add BB_LIMITEDDEPS supportRichard Purdie2017-01-201-0/+1
| | | | | | | | | | | When we're running with bitbake -b, BB_TASKDEPDATA is incorrect and limited. We really need a way to know this from the metadata and this new variable provides this in worker context. This means existing code can stop having to guess. (Bitbake rev: 05763bc886024dcce2ce6b3060fb00abf79a9402) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-30 17:23:38 +0000