summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/runqueue.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: runqueue: add task hash to Queue eventsAlexandru DAMIAN2013-09-221-0/+5
| | | | | | | | | | Adding the sstate-related hash for all runqueue and scenequeue tasks, as it's needed in the WebHob data. (Bitbake rev: b6e2ce1cf7a0ede890f08fabf536a556dc4263c5) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: build, runqueue: adds info to the *runQueue* eventsAlexandru DAMIAN2013-09-221-0/+10
| | | | | | | | | | | | | | | | | | | This patch adds task identifying information for all runQueue and sceneQueue events, and for bb.build.Task* events. This will allow matching event to specific tasks in the UI handlers processing these events. Adds RunQueueData functions to get the task name and task file for usage with the runQueue* events. Adds taskfile and taskname properties to bb.build.TaskBase. Adds taskfile and taskname properties to the *runQueue* events (Bitbake rev: b4a5e4be50d871a80dbe0993117d73f5ad82e38f) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker,runqueue: send the task dependency treeAlexandru DAMIAN2013-09-221-0/+5
| | | | | | | | | | | | | | | Adding a CookerFeature that allows UIs to enable receving a dependency tree once the task data has been computed and the runQueue is ready to start. This will allow the clients to display dependency data in an efficient manner, and not recompute the runqueue specifically to get the dependency data. (Bitbake rev: 75466a53b6eece5173a9bfe483414148e4c06517) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: add runQueueTaskSkipped eventAlexandru DAMIAN2013-09-171-3/+12
| | | | | | | | | | Adding a runQueueTaskSkipped to notify that the tasks that are not run either because they are set-scened or they don't need an update (timestamp was ok). (Bitbake rev: cf4a0c7aa82090876ae652b611acfab3ce2688f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: runqueue: add sceneQueueTaskCompleted eventAlexandru DAMIAN2013-09-101-0/+6
| | | | | | | | | | | Adding an event to be fired when a scene task is completed. It is analogous to the run task completed event, and has been missing for some reason. (Bitbake rev: 73b8f4d3fbeaf1b330a66d76012d0a5cef8dbe2d) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: check whether multiple versions of the same PN are due ↵Robert Yang2013-09-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to be built There would be an race issue if we: $ bitbake make-3.81 make-3.82 This because they are being built at the same time which would cause unexpected problems, for example: [snip] ERROR: Package already staged (/path/to/tmp/sstate-control/manifest-qemux86-make.populate-sysroot)?! ERROR: Function failed: sstate_task_postfunc [snip] Or there would be python's strack trace such as: [snip] *** 0004: mfile = open(manifest) 0005: entries = mfile.readlines() 0006: mfile.close() 0007: 0008: for entry in entries: Exception: IOError: [Errno 2] No such file or directory: xxx [snip] [YOCTO #5094] We can quit earlier to avoid this kind of issue when two versions of the same PN are going to be built since this isn't supported. (Bitbake rev: ab377c00c33a2d296bfda1b0b6c2a62b29d1004f) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Ensure ${DATE} and ${TIME} are consistentPeter Kjellerstedt2013-09-061-0/+2
| | | | | | | | | | | | | | | Due to the worker split the ${DATE} and ${TIME} variables could end up with different values for different workers. E.g., a task like do_rootfs that is run within a fakeroot environment had a slightly different view of the time than another task that was not fakerooted which made it impossible to correctly refer to the image generated by do_rootfs from the other task. (Bitbake rev: 756cc69ebf8bfe8455d0c90f288dd51be2499773) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-worker: ensure BUILDNAME is available during executionPaul Eggleton2013-09-041-0/+1
| | | | | | | | | | | | | | | BUILDNAME is set from cooker by default, so since the worker split it will not be set when executing functions. In OpenEmbedded this results in /etc/version (which is populated from BUILDNAME) not having any content. Pass this variable value through to the worker explicitly to fix the issue. Fixes [YOCTO #4818]. (Bitbake rev: 92940b0427d9b2b3f95e27c230ec1e36638a34bc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix scenequeue to pass file descriptors, not a floatRichard Purdie2013-09-021-1/+1
| | | | | | | | This was missed off in a previous patch. (Bitbake rev: ad7664edd40fa46e6f6fec2144403e3b6fc3a639) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process, server/xmlrpc, runqueue: Use select.select() on ↵Richard Purdie2013-09-011-2/+10
| | | | | | | | | | | | | | | | | | | | | | fds, not time.sleep() The existing backend server implementations were inefficient since they were sleeping for the full length of the timeouts rather than being woken when there was data ready for them. It was assumed they would wake and perhaps did when we forked processes directory but that is no longer the case. This updates both the process and xmlrpc backends to wait using select(). This does mean we need to pass the file descriptors to wait on from the internals who know which these file descriptors are but this is a logical improvement. Tests of a pathaolgical load on the process server of ~420 rapid tasks executed on a server with BB_NUMBER_THREAD=48 went from a wall clock measurement of the overall command execution time of 75s to a much more reasonable 24s. (Bitbake rev: 9bee497960889d9baa0a4284d79a384b18a8e826) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-25 10:49:50 +0000