linux/poky.git/bitbake/lib/bb/cooker.py, branch uninative-2.5

bitbake: bitbake: Strip old editor directives from file headers

2019-05-04T09:44:10+00:00

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

bitbake: bitbake: Drop duplicate license boilerplace text

2019-05-04T09:44:10+00:00

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

bitbake: bitbake: Add initial pass of SPDX license headers to source code

2019-05-04T09:44:04+00:00

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

bitbake: cooker: Fix bbfile_config_priorities when BBFILE_PATTERN is empty

2019-03-24T17:01:34+00:00

The layer was not in bbfile_config_priorities when BBFILE_PATTERN is empty, this caused "bitbake-layers show-layers" can't show these layers, this was incorrect since these layer did exist. Add these layer to bbfile_config_priorities can fix the problem. Fixed: Add BBFILE_PATTERN_core = "" in oe-core/meta/conf/layer.conf $ bitbake show-layers | grep oe-core There was nothing, now the layer is shown (Bitbake rev: 0ff5cdb0cca9266ca29127639494bcfd95e36831) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: cooker: Tweak multiconfig dependency resolution

2019-02-25T10:43:31+00:00

There were a couple of problems with the multiconfig dependency resolution: - the "if mc" condition triggering this code wasn't correct, it needs to be "if more than one multiconfig" configured - after adding providers we need to call add_unresolved again and rebuild mcdeps within the "while new" loop By fixing these issues we allow various other combinations of multiconfig builds to work which previously didn't. [YOCTO #13090] [YOCTO #13130] (Bitbake rev: 4359b037de578095db2595f119dfb8e3340e1414) Signed-off-by: Richard Purdie

bitbake: cooker: Split recipes to parse amongst threads ahead of time

2019-01-08T11:16:03+00:00

We have two choices, split the recipes amongst the parsing threads in blocks ahead of time, or have a queue which parsers pull from when idle. The optimum approach depends on how similar the pieces are. For the single recipe reparse case, there is currently a significant wait for the feeder thread to start (around 0.25s in a 2s command). Its possible splitting into blocks in advance may be unluckly for some other workloads but experimentally it seems to work better overall for me at least. (Bitbake rev: ae79868861568d673a70472e85a4bde9e2d84a8f) Signed-off-by: Richard Purdie

bitbake: cooker: Remove Feeder() since its no longer needed with moderm multiprocessing

2019-01-08T11:16:03+00:00

There used to be many bugs in multiprocessing and we implemented our own feeder process to avoid them. Now that we have python 3.x, these are fixed and just using the standard Queue mechanism appears to work fine. We can therefore drop the unneeded code and simplify. (Bitbake rev: b2d39fc37fcf3c81a562ec1ef4f8b4c1a493fc57) Signed-off-by: Richard Purdie

bitbake: cooker: fix indirect multiconfig dependencies

2019-01-03T12:36:55+00:00

When an indirect multiconfig dependency exists, such as: A depends on B, B has a multiconfig dependency to C,and our build target is A, the multiconfig dependency to C is not processed on time, hence no providers are added for it, causing an exception in the runqueue because the dependency does exist in it. Call add_unresolved() for all available multiconfigs before processing providers for multiconfig dependencies, detecting mcdepends on time so providers for them can be added correctly. (Bitbake rev: 8a6bc7584ad61b4de98af92a86066602006262f9) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie

bitbake: cooker: Add some timing debug messages to the server startup

2018-12-08T17:17:37+00:00

We're seeing slow startup in bitbake, add some timeing debug messages so the logs are more useful for debugging when its slow. (Bitbake rev: 8d1fc115b8a176009f1f3a8ce840b422e7e0b45e) Signed-off-by: Richard Purdie

bitbake: cooker: Fix multiconfig dependencies

2018-11-22T10:45:14+00:00

When multiconfig is enabled the cooker adds providers for all the targets to be built on all the multiconfig variables that were set, regardless if there is a dependency to it or not. This causes an issue when a certain target is incompatible with one or more of the multiconfigs, e.g. the target is not in COMPATIBLE_MACHINE for one of the MACHINEs being built, causing the cooker to error out since no providers can be found for that certain target on that multiconfig. This patch modifies the behavior to only look for PROVIDERS for a target on the multiconfig that was selected to be built, PROVIDERS are then looked for in other multiconfigs only when there is a defined dependency to them. [YOCTO #12985] (Bitbake rev: f2106a3a767542359fdde238abcf5fe35ab3a144) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie