linux/poky.git/scripts/yocto-compat-layer.py, branch uninative-2.6

scripts: rename yocto-compat-layer to remove "compatible" nomenclature

2017-09-21T10:34:19+00:00

"Yocto Project Compatible" [1] is a programme which requires you meet specific criteria including going through an application process - it is not sufficient simply to run the script we have created here and have it produce no warnings/errors. To avoid people being confused by the fact that this script uses the term "compatible" or variations thereof, substitute usage of that word with "check" instead. The functionality of the script is unchanged. [1] https://www.yoctoproject.org/ecosystem/yocto-project-branding-program (From OE-Core rev: 2a6126a115f10750ea89f95629d3699ad41c5665) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

yocto-compat-layer.py: Fix trace when layers can't be processed

2017-09-11T16:30:28+00:00

When all of the requested layers have unsatisfied dependencies, an error can occur. Check for the condition to avoid the traceback: Traceback (most recent call last): File "../scripts/yocto-compat-layer.py", line 203, in ret = main() File "../scripts/yocto-compat-layer.py", line 194, in main if not results[layer_name].wasSuccessful(): AttributeError: 'NoneType' object has no attribute 'wasSuccessful' (From OE-Core rev: 32c9b3d99a0c27f6736696082b9da812a8464bf8) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

yocto-compat-layer.py: apply test_signatures to all layers

2017-07-06T13:38:14+00:00

Software layers were previously allowed to change signatures, but that's not desired for those layers either. The rule that a layer which is "Yocto Compatible 2.0" must not change signatures unless explicitly requested holds for all kinds of layers. However, as this is something that software layers might not be able to do right away, testing for signature changes in software layers can be disabled. It's on by default, as that was Richard's recommendation. Whether that should change needs further discussion as part of finalizing "Yocto Compatible 2.0". As it might still change, the tool now has both a with/without parameter so that users of the tool can choose the desired behavior without being affected by future changes to the default. (From OE-Core rev: e7fe215f50a1b75771f33fffdda529a95c026d3f) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts/yocto-compat-layer.py: Return non-zero when layer test fail

2017-06-09T16:12:14+00:00

If whatever layer tested fails returns 2 to indicate the failure. [YOCTO #11482] (From OE-Core rev: c00102e7b67e5f21247094d41943d767ad13db88) Signed-off-by: Aníbal Limón Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

yocto-compat-layer: test signature differences when setting MACHINE

2017-04-13T09:54:10+00:00

Selecting a machine is only allowed to affect the signature of tasks that are specific to that machine. In other words, when MACHINE=A and MACHINE=B share a recipe foo and the output of foo, then both machine configurations must build foo in exactly the same way. Otherwise it is not possible to use both machines in the same distribution. This criteria can only be tested by testing different machines in combination, i.e. one main layer, potentially several additional BSP layers and an explicit choice of machines: yocto-compat-layer --additional-layers .../meta-intel --machines intel-corei7-64 imx6slevk -- .../meta-freescale To simplify the analysis and limit the amount of output, mismatches are sorted by task order such that tasks that run first are also reported first. Following tasks for the same recipe and set of machines then get pruned, because they are likely to be different because of the underlying task (same approach as in test_signatures). The difference here is that we get information about all machines. The task order in the base configuration serves as heuristic for sorting that merged list. The test has already found issues in go-cross (depended on tune-specific libgcc) and gdb-cross (had a tune-specific path unnecessarily), so it is also useful to uncover issues that are not caused by the BSP layer itself. (From OE-Core rev: cb0d3de4540e412cfcb7804b4b1689141c80e3a1) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

yocto-compat-layer: add --additional-layers

2017-04-12T14:09:58+00:00

The new --addditional-layers parameter takes a list of layer directories and adds them to the build configuration before starting testing. The resulting base configuration then more closely matches a full distro. This is relevant in two cases: 1. some layers like meta-freescale dynamically enable more recipes in their layer.conf depending on which other layers are active, so testing only against OE-core might miss problems which occur only when also some other layers are active 2. BSP layers might be fine in combination with machines from OE-core, but might break in combination with some other machines As before, test_signatures only warns about signature changes introduced by the layer which is under testing, and not those changes introduced by the additional layers. (From OE-Core rev: 0e8528f7c6201e8a5d2799123241c0e1b85081ce) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

yocto-compat-layer: also determine tune flags for each task

2017-04-12T14:09:58+00:00

locked-sigs.inc groups tasks according to their tune flags (allarch, i586, etc.). Also retrieve that information while getting signatures, it will be needed to determine when setting a machine changes tasks that aren't machine-specific. (From OE-Core rev: 67f9a8759f47680dbf349797801b2a1e8d149377) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

yocto-compat-layer.py: Fix the signature validation

2017-04-05T22:22:13+00:00

The initial signatures need to be collected -after- the dependency layers have been added to the system. Otherwise changes that happen due to dependencies, outside of the layer being scanned, will show up as signature problems. The add_layer function was split into two pieces so that we can process the dependencies first, and then add the layer itself for the comparison. (From OE-Core rev: 4eb0932e755b7cb582a8db811aeed1397ecb92cc) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

yocto-compat-layer.py: Add --dependency argument

2017-04-05T22:22:13+00:00

When processing a large number of items, there are times that it would be nice to be able to pass in a series of layers that can be used as dependencies for the layer that is being scanned. This avoids the significant overhead of processing all of the layers to compatibility. (From OE-Core rev: 57fc8a9771174b7d0533a42c045053adefa537a8) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

yocto-compat-layer.py: Add status for skipped items

2017-04-05T22:22:12+00:00

If items were skipped because the dependencies could not be found, we want to record this was skipped so we can display it later. (From OE-Core rev: 402ef1c8bd1ea994581a39672f31ab1203a0899d) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton Signed-off-by: Richard Purdie