summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/runqueue.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: runqueue: report close matches for an invalid task namePaul Eggleton2013-08-161-1/+7
| | | | | | | | | | Help to pick up mistakes such as "bitbake -c cleanstate xyz" (instead of "bitbake -c cleansstate xyz".) (Bitbake rev: 15c3db1cffdffd85641c6b12e77f19ce7a553472) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: runqueue: add warning if invalidating invalid taskPetter Mabäcker2013-07-291-0/+3
| | | | | | | | | | | | | Add a warning if 'bitbake -C' is executed with a task that does not exist. Fixes [YOCTO #4877] (Bitbake rev: 6459c1d0eb8f1007246df36149e2496ee531e25f) Signed-off-by: Petter Mabäcker <petter@technux.se> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue/build: Add recideptask flagRichard Purdie2013-06-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Currently, tasks like fetchall are slightly broken since if a recipe has specific [depends] which occur after do_fetch and add items not listed in DEPENDS and RDEPENDS, they are not caught by recrdeptask. We've gone around in circles on this issue (e.g http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/runqueue.py?id=5fa6036d49ed7befe6ad50ec95c61a50aec48195 ) and in many cases the behaviour of recrdepends is correct but tasks like fetchall need the other behaviour. To address this we add a recideptask flag which can be used in conjuction with the recrdeptask flag to specify which task to to the inspection upon. This means entries like do_rootfs[depends] which have do_fetch tasks are caught and run. I'm not 100% happy with needing another flag but I don't see any rational way to get the correct behaviour in all cases without it. [YOCTO #4597] (Bitbake rev: f8c9b292b02ce2c28741b74901205f5e5807ca87) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve handling of failing setscene tasks with hard ↵Richard Purdie2013-06-141-3/+7
| | | | | | | | | | | | | | | | | | | | | | | dependencies If a setscene task has a hard dependency on a task like pseudo-native, its expected that the setscene task will not run unless the dependency is met. This adds code to ensure that is the case, otherwise a bug would show up with a usecase like: bitbake gnome-common bitbake pseudo-native -c cleansstate bitbake gnome-common -c clean bitbake gnome-common With the double wrapper script environment, we'd not see issues like this as it would be masked. The problem theoretically affects code like useradd too as well as anything using a sstate postinstall. (Bitbake rev: c54e738e2b5dc0d8e6fd8e93b284ed96e7a83051) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv: Adapt autostart to bitbake-workerRichard Purdie2013-06-141-0/+1
| | | | | | | | | | With the change to bitbake-worker we need to ensure the workers know how to contact the PR service, the magic 0 port and singleton is no longer enough. (Bitbake rev: c761751e259bb8e940552a28794b45887b5a72d9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Spawn a separate worker for fakeroot tasksRichard Purdie2013-06-141-17/+58
| | | | | | (Bitbake rev: 860ec42b220b7ed3f3bbe52c3546bba66644eac8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Abstract the start and teardown worker functionsRichard Purdie2013-06-141-17/+31
| | | | | | | | | We're going to need a fakeroot/pseudo version of the worker so abstract the code to start the worker process. (Bitbake rev: b5d0f12f9df3ab211700473ed145ee6fbd9ca8e9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Move the bitbake-worker execution to a higher levelRichard Purdie2013-06-141-59/+55
| | | | | | | | | | The worker was being executed by each execution queue so would get constructed twice for each build. This is wasteful so move execution to the main runqueue so we only have to start the worker once. (Bitbake rev: 8117f8480125b121b2b5ac0afc31b108d9e670ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Split runqueue to use bitbake-workerRichard Purdie2013-06-141-178/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty fundamental change to the way bitbake operates. It splits out the task execution part of runqueue into a completely separately exec'd process called bitbake-worker. This means that the separate process has to build its own datastore and that configuration needs to be passed from the cooker over to the bitbake worker process. Known issues: * Hob is broken with this patch since it writes to the configuration and that configuration isn't preserved in bitbake-worker. * We create a worker for setscene, then a new worker for the main task execution. This is wasteful but shouldn't be hard to fix. * We probably send too much data over to bitbake-worker, need to see if we can streamline it. These are issues which will be followed up in subsequent patches. This patch sets the groundwork for the removal of the double bitbake execution for psuedo which will be in a follow on patch. (Bitbake rev: b2e26f1db28d74f2dd9df8ab4ed3b472503b9a5c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Split data from configurationRichard Purdie2013-06-071-6/+6
| | | | | | | | | | | The reasons for combining these objects is ancient history, it makes sense to clean things up and separate them out now. This follows on logically from the configuration cleansups and leads well into the bitbake-worker changes. (Bitbake rev: 89ffd62661ebcf2a97ce0c8dfd5e4d5bfbe27de7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Ensure export flag is set for fakeroot environment ↵Richard Purdie2013-05-221-0/+1
| | | | | | | | | | | | variables This means the variables show up in the shell execution "run" files since its useful to know what the fakeroot environment is and how to set it up manually. (Bitbake rev: bdf437747b664479acde6deaa9096e2a6bcdf483) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Separate out collections handling code into its own classRichard Purdie2013-05-121-2/+2
| | | | | | | | | | The Cooker class is too large and needs to be split up into different functional units. Splitting out the collections code into its own class seems like a good place to start to try and disentangle things. (Bitbake rev: ca1fcbb6e214c155a05328779d3d326e10c5eac0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Use taskData.fn_index[depdata] instead of uninitialized depMartin Jansa2013-03-191-2/+2
| | | | | | | | | | | | | | | | | | | | * dep variable was removed in commit 3190cb83e2af195a464f669c5aa8aedbf795160e Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Wed Jun 27 11:04:06 2012 +0100 taskdata: Add gettask_id_fromfnid helper function This is like gettask_id but doesn't require translation of fnid -> fn first which the function then translates back. This gives a sizeable performance improvement since a significant number of lookups are avoided. * now it fails completely instead of showing which task is missing (Bitbake rev: 58847fabd389e5b8d02d5a9c6827aabedb30312f) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build.py: Dump out performance data of individual tasksRichard Purdie2013-01-281-1/+2
| | | | | | | (Bitbake rev: 32aa49519e4f015e3c21466a7e5dc939f6369851) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Allow partial setscene task coverageRichard Purdie2012-11-201-11/+72
| | | | | | | | | | | | | | | | | | | | | | | | When the setscene code was originally written it was thought that we'd allow "partial" coverage. For example, if we just want to build the target "bash:do_populate_sysroot" and its available from sstate, it makes no sense to install gcc-cross's sstate package as its simply not needed. Due to various other issues in the codebase, this functionality was disabled/removed to allow the setscene code and sstate to stabilise and allow us to concentrate on other problems. The time has now come to enable "partial" coverage. There are two major changes in this patch: a) Creation of an unskippable list. This lists direct dependencies of build targets and hence things that cannot be skipped. b) Addition of a handler which looks at a given setscene target and what depends on it and then decides whether its necessary. (Bitbake rev: 2a937cd6a6c3110030b40bc4d85e349b85cb4db7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add --no-setscene to skip all setscene tasksJason Wessel2012-09-241-6/+7
| | | | | | | | | | | Mainly intended for the purpose of debugging or forcing builds from source, the --no-setscene will prevent any setscene tasks from running. (Bitbake rev: 440e479f3e248482c38c149643403c6907ac7034) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/runqueue.py: fix exceptions with -k and failed targetsPaul Eggleton2012-09-241-1/+3
| | | | | | | | | | | | | | | | | | If a target dependency is marked as failed and yet we are continuing on because -k has been specified, don't try to access the dependency's data in taskData.build_targets since it will have been removed. This fixes "IndexError: list index out of range" errors in this situation. Also, do not print the "unhandled exception" message when SystemExit is raised since we will have reported the actual error already in this case (e.g. when -k has been specified and some targets failed). Fixes [YOCTO #3133]. (Bitbake rev: 70eebc184eb1ab3678be87bed019b5beadecdc89) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Clean up runqueue exception catching in the normal ↵Richard Purdie2012-08-021-0/+3
| | | | | | | | task failure case (Bitbake rev: a0bc58031d4eb31f8587171e870ecad059af5098) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Wipe out the stamp cache between setscene and main ↵Richard Purdie2012-07-261-0/+2
| | | | | | | | | | | task execution The stamp files can change during setscene and the cache should be cleared to account for this. (Bitbake rev: 5ec12f586a50fce675b268965b3dc487aaa96c43) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Allow the setsceneverify function to have a list of ↵Richard Purdie2012-07-261-3/+24
| | | | | | | | | | | | | | | | | | | | tasks that are invalid and need to run There was some odd behaviour if some task was run from setcene whilst there were existing valid stamps for a depepdency. For example, do_populate_sysroot might be installed at setscene time but if there were other tasks not installed from setscene such as do_populate_lic which depend on do_configure, the setsceneverify function would think that do_configure needed to be rerun and would hence void the do_populate_sysroot and force that to rerun too. The setsceneverify function needs to know which tasks are going to be rerun, not just what the overall task list is and what setscene functions have run. This patch adds that information and maintains backwards compatibility in a slightly ugly but effective way. The metadata needs updating to take advantage of this change. (Bitbake rev: 1423aafff97f17169e95ec3ba973eb002ff98c1c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Ensure one setscene function doesn't mask out another ↵Richard Purdie2012-07-261-2/+5
| | | | | | | | | | | | | which needs to run The scenequeue code could result in one setscene function masking out another which had been marked as notcovered. This change ensures the notcovered list is taken into account when deciding which tasks need to be run, ensuring that tasks that should be run do get run. (Bitbake rev: 95b31127d8ba12ccb061d67481ece134c18c39f2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Optimise the hashvalidate call to only process tasks ↵Richard Purdie2012-07-261-0/+6
| | | | | | | | | | | | | we may actually want Currently we call the hashvalidate for anything without a valid setscene stamp. This improves the code to account for existing stamp files so that we only process setscene hashes for things we might actually end up using. This avoids hash processing and makes things slightly more efficient and the logs less confusing. (Bitbake rev: 2e71a65bd910e8be894b8284eb0a50de7270c081) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Gracefully exit if an exception occurs in the runqueue ↵Richard Purdie2012-07-261-1/+9
| | | | | | | | | | | | | | | execution code There was a bug where an exception in the runqueue code would cause an infinite loop of debug messages. The exception would get reported but would loop since runqueue was still registered as an idle handler. This patch adds an exception handler to ensure in the case of errors, the system more gracefully shuts down and doesn't loop. (Bitbake rev: 99467c7e387f6e71358b40b8afae450d72cd68e0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Fix a stamp comparision bugRichard Purdie2012-07-261-6/+9
| | | | | | | | | | | | | | | We check the stamp cache before comparing t2 and t3 which means that we can miss a level in the stamp file chains. The result of this is that a stamp can be accepted as valid when in fact it isn't. Some weird behaviour alerted me to this in a local build. This patch also fixes to only uses the cache in recurse mode, there was a corner case where stamps not in recurse mode could get added to the cache which could cause an issue potentially. (Bitbake rev: 7a5f776d325c0e37f58003424beda7cae2695325) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Improve error output to be more useful when ↵Richard Purdie2012-07-171-1/+1
| | | | | | | | non-existent tasks are found (Bitbake rev: 9be584272a63f48d8dc7c9f05b017d11250aa247) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Fix recursive task pruning to only prune self ↵Richard Purdie2012-07-041-2/+4
| | | | | | | | referencing tasks (Bitbake rev: 4962a59793504b26b06cf058dda600a07fbbd951) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Allow recrdeptasks that have self referencesRichard Purdie2012-07-041-2/+7
| | | | | | | | | | | | | | | | | | | | | | In some cases we want to pull in DEPENDS and RDEPENDS of recrdeptask dependencies but we need a way to trigger or avoid this behaviour depending on context. The logical syntax to trigger such behaviour would be a self referencing recrdeptask: do_a[recrdeptask] = "do_a do_b" The dependency chains already recurse this kind of expression correctly, the missing piece is to avoid any circular reference errors. Since the dependencies have already been recursively resolved, simply removing any recrdeptask references is enough to break the circular references. This patch therefore removes any circular references using the set difference_update() operator. There will be metadata tweaks required to add any references needed to the extra taskname. (Bitbake rev: a5324da9b8a0c9307a6c511ea9009f34be70c92b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Handle multiple rdeptask entriesRichard Purdie2012-06-281-2/+2
| | | | | | | | | | I'm not sure why we don't currently allow multiple entries in rdeptask when we do in deptask. This makes the handling match between the two since its trivial to fix. (Bitbake rev: 19c84fe8854639768c874cc1449963a9867ad397) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Reimplement recrdepends so it works more correctlyRichard Purdie2012-06-281-58/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, recrdepends is extremely greedy. For example: do_foo[rdepends] = "somedep:sometask" addtask foo which adds foo with *no* dependencies, will suddenly start appearing as a dependency in every task which uses recrdepends. So far this has been mildy annoying but we now have use cases where this makes no sense at all. This reworks the recrdepends code to avoid this problem. To do this we can no longer collapse things into lists just based on file ID. The problem is this code is extremely performance sensitive. The "preparing runqueue" phase spends a lot of time in these recursive dependency calculations so any change here could negatively impact the user experience. As such, this code has been carefully tested on convoluted dependency trees with operations like "time bitbake world -g". The net result of this change and the preceeding changes combined is a net speed up of these operations in all cases measured. Tests were made comparing "bitbake world -g" task-depends.dot before and after this patch. There *are* differences for example -nativesdk do_build dependencies on -native recipes are no longer present. All removed dependencies appear to be sensible improvements to the system. The "rdepends" cross contamination issue above is also fixed. (Bitbake rev: 82d73423c57569b984ee0ae3d93e3c3bd5dc5216) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Convert depends variable to use setsRichard Purdie2012-06-281-12/+8
| | | | | | | | | This gives some small performance gains and sets the scene for other improvements by removing the need for duplicate detection code. (Bitbake rev: 6fd723479e8d49227fd58040b3485c1d5afc4bc5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskdata: Add gettask_id_fromfnid helper functionRichard Purdie2012-06-281-8/+4
| | | | | | | | | | This is like gettask_id but doesn't require translation of fnid -> fn first which the function then translates back. This gives a sizeable performance improvement since a significant number of lookups are avoided. (Bitbake rev: 3190cb83e2af195a464f669c5aa8aedbf795160e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskdata.py: Add support for rdepends task flagRichard Purdie2012-06-251-1/+13
| | | | | | | | | | Currently its not possible to add arbitrary RDEPENDS to a specific task. This can be useful and this patch adds functionality equivalent to the 'depends' task flag. (Bitbake rev: db65080a6199baecc5c422294a4c4a9fd12dc29e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: utils.py: Add function to set nonblocking operation on a file ↵Richard Purdie2012-06-251-1/+1
| | | | | | | | descriptor (Bitbake rev: ab6d71ebfcfb7bedc064b25f84647c8815096e5a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: add -C option to invalidate a task and rebuild the targetPaul Eggleton2012-06-211-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | This new command line option forces the specified task and all dependent tasks up to the default task to re-run. This means that the following single step: bitbake -C compile somerecipe is equivalent to the following two steps (with the recent change to -f): bitbake -c compile -f somerecipe bitbake somerecipe Note that to work this option needs full hashing enabled (i.e. BB_SIGNATURE_HANDLER must be set to a signature handler that inherits from BasicHash). If this is not the case, -C effectively does nothing. Based on a previous implementation of this option by Jason Wessel <jason.wessel@windriver.com>. Implements [YOCTO #2615]. (Bitbake rev: 2530e0faada5775897cfd1b93aba6925826dca73) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: ensure -f causes dependent tasks to be re-runPaul Eggleton2012-06-211-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If -f is specified, force dependent tasks to be re-run next time. This works by changing the force behaviour so that instead of deleting the task's stamp, we write a "taint" file into the stamps directory, which will alter the taskhash randomly and thus trigger the task to re-run next time we evaluate whether or not that should be done as well as influencing the taskhashes of any dependent tasks so that they are similarly re-triggered. As a bonus because we write this file as <stamp file name>.taskname.taint, the existing code which deletes the stamp files in OE's do_clean will already handle removing it. This means you can now do the following: bitbake somepackage [ change the source code in the package's WORKDIR ] bitbake -c compile -f somepackage bitbake somepackage and the result will be that all of the tasks that depend on do_compile (do_install, do_package, etc.) will be re-run in the last step. Note that to operate in the manner described above you need full hashing enabled (i.e. BB_SIGNATURE_HANDLER must be set to a signature handler that inherits from BasicHash). If this is not the case, -f will just delete the stamp for the specified task as it did before. This fix is required for [YOCTO #2615] and [YOCTO #2256]. (Bitbake rev: f7b55a94226f9acd985f87946e26d01bd86a35bb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: Drop check_stamp_fn, it's obsolete and should not be usedRichard Purdie2012-05-111-11/+0
| | | | | | | | | | This function was used by old code such as packaged staging but is thankfully obsolete now and replaced with better mechanisms. Its time to remove it and the horrible internal only variables associated with it. (Bitbake rev: 2995b8d551e0532eca20f8862730acd062c608ad) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: Drop check_stamps function, it is obsolete and unusedRichard Purdie2012-05-111-94/+0
| | | | | | | | | | | This was originally used to check the consistency of the stamps in one function call. This turns out to be inefficient, unnecessary and if it were necessary, check_stamp_task() could be called in a loop. The function has been unmodified for a while and likely contains bugs. Its best simply removed. (Bitbake rev: 728ffde1bd69b880d48fe8523b1616956d13616e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: Fix 'full' stamp checking to be more efficient and cache ↵Richard Purdie2012-05-111-6/+16
| | | | | | | | | | | | | | results This should fix issues where bitbake would seemingly lock up when checking certain configurations of stampfiles. The cache is kept within the runqueue since that feels like the right place to associate this cache data. (Bitbake rev: e95755c4931b26d9f8102ed3652dff969145cfc9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: drop unnecessary keys() in runqueue_process_waitpidChristopher Larson2012-05-111-1/+1
| | | | | | | (Bitbake rev: d03dc07dea2f4e594fdbe4abe618670fe628a7c9) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: handle task exit due to signal/stopChristopher Larson2012-05-111-11/+22
| | | | | | | | | | | | | | | | - for a normal exit, use WEXITSTATUS, rather than manually shifting - for exit via signal, set the exit code to 128+N, per shell convention - if a process was stopped, return and don't handle it, as the process can yet be continued This should fix the case where bitbake says a task failed with an exit code of 0 (we assumed failure based on the overall status, but didn't pass all the information along to task_fail). (Bitbake rev: 84ea614bc56d35a414eb5bf5658891b340bfc569) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: wait and deal with those <defunct> sub-processes as soon as they ↵Shane Wang2012-03-301-0/+1
| | | | | | | | | | | | | | | are os.killed() when "Force stop" When "Force stop" is performed during the build stage, after os.kill() kills the build sub-processes, there are many <defunct> python processes in the system. In Hob, when the user initiates a new build, os.waitpid() in runqueue_process_waitpid() will be called, and the pids of those <defunct> processes will be returned as result[0], then self.build_pids[result[0]] will throw KeyError exception because now for the new build self.build_pids is empty. This patch is to address the above issue to collect the results and handle the sub-processes as soon as they are killed. [Yocto #2186] (Bitbake rev: e9f4ca467e795bbc520d12b0e7a5985b6ff0a20e) Signed-off-by: Shane Wang <shane.wang@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Typo: "nonexistant" -> "non-existent"Robert P. J. Day2012-03-201-2/+2
| | | | | | | (Bitbake rev: c4c8df0e1e77f99f3ee0b07e1748116fc362819f) Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: When checking whether stamps are valid for setscene, recurseRichard Purdie2012-03-161-3/+4
| | | | | | | | | | | | | | | | | | | | | | Currently the code checking whether stamps are valid only traverses one step of the dependency graph. This works fine in the normal cases where we've already validated dependencies but for the setscene code, it doesn't work well. A typical problem usecase is something like: bitbake gcc-cross -c unpack -f bitbake gcc-cross which will ignore any sstate files already cached which could be used to speed up the gcc-cross build. This becomes particularly problematic with multiple gcc builds where only one should rebuild yet they all do. This patch teaches the stamp code to be able to recurse within a given fn which gives the behaviour people would expect from the code and allows bitbake to make better use of prebuild sstate objects. (Bitbake rev: e68814cb2e8da523d4ddf05e8ceddfaa19244851) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/classes: Convert to use appendVar and appendVarFlagsRichard Purdie2012-03-051-4/+4
| | | | | | (From OE-Core rev: 3b57de68e70e77dbc03c0616a83a29a2e99e40b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: fix python error on scenequeue task failurePaul Eggleton2012-03-011-2/+1
| | | | | | | | | | | | Fixes a regression introduced in commit e8a3499c95a6d4f2b8fed002fb9504733c5be3c6 which resulted in a backtrace on setscene task failure due to trying to dereference the setscene task ID twice. (Bitbake rev: 8b846a92a58b5c20d7cfd2efd32b763e95c3c2fd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: initialize rqexe at RunQueue's init functionDongxiao Xu2012-03-011-0/+5
| | | | | | | | | | | | | | | | Sometimes user stops the build before runqueue is established, for example, at the stage of running add_unresolved() function. This will cause RunQueue to use rqexe field in finish_runqeue() before initialized. This will cause endless print of "Running idle function" if use process server. This commit initialize rqexe variable in RunQueue's init function, and add a judgement in finish_runqueue(). (Bitbake rev: 59f817723172092a87738c79f555e605f55ea375) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fix setscene task start/failure handlingPaul Eggleton2012-02-281-5/+13
| | | | | | | | | | | | | * When a setscene task starts, print out that it's starting in the UI (ensuring we get the correct task name) * When a setscene task fails, ensure we remove it from the list of running tasks so that if you break out any time afterwards it is not still listed. (Bitbake rev: e8a3499c95a6d4f2b8fed002fb9504733c5be3c6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: make dry-run do everything except executePaul Eggleton2012-02-281-7/+2
| | | | | | | | | | | | Make dry-run do everything except executing the task, instead of cutting it off earlier. This fully tests the code path for running the child task (parsing and fakeroot), as well as enabling future functionality such as using dry-run to produce signature files. (Bitbake rev: bf1d7739618dabf3872a868230c0112b9ad2a2c0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* V5 Disk space monitoringRobert Yang2012-02-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Monitor disk availability and take action when the free disk space or amount of free inode is running low, it is enabled when BB_DISKMON_DIRS is set. * Variable meanings(from meta-yocto/conf/local.conf.sample): # Set the directories to monitor for disk usage, if more than one # directories are mounted in the same device, then only one directory # would be monitored since the monitor is based on the device. # The format is: # "action,directory,minimum_space,minimum_free_inode" # # The "action" must be set and should be one of: # ABORT: Immediately abort # STOPTASKS: The new tasks can't be executed any more, will stop the build # when the running tasks have been done. # WARN: show warnings (see BB_DISKMON_WARNINTERVAL for more information) # # The "directory" must be set, any directory is OK. # # Either "minimum_space" or "minimum_free_inode" (or both of them) # should be set, otherwise the monitor would not be enabled, # the unit can be G, M, K or none, but do NOT use GB, MB or KB # (B is not needed). #BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" # # Set disk space and inode interval (only works when the action is "WARN", # the unit can be G, M, or K, but do NOT use the GB, MB or KB # (B is not needed), the format is: # "disk_space_interval, disk_inode_interval", the default value is # "50M,5K" which means that it would warn when the free space is # lower than the minimum space(or inode), and would repeat the action # when the disk space reduces 50M (or the amount of inode reduces 5k) # again. #BB_DISKMON_WARNINTERVAL = "50M,5K" [YOCTO #1589] (Bitbake rev: 4d173d441d2beb8e6492b6b1842682f8cf32e6cc) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue: Ensure finish_now() sets the runqueue state consistentlyRichard Purdie2012-02-261-0/+7
| | | | | | | | | | If we call finish_now(True), rq.state is not updated to match. This makes the behaviour of finish_now(False) and finish_now(True) consistent so both leave rq.state consistently. (Bitbake rev: 9079ae0ab74f9232b7e9853b2013b051d4fcf623) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-17 03:28:24 +0000