aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/yocto-compat-layer.py
AgeCommit message (Collapse)Author
2017-07-06yocto-compat-layer.py: apply test_signatures to all layersPatrick Ohly
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. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-06-09scripts/yocto-compat-layer.py: Return non-zero when layer test failAníbal Limón
If whatever layer tested fails returns 2 to indicate the failure. [YOCTO #11482] Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-04-12yocto-compat-layer: test signature differences when setting MACHINEPatrick Ohly
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. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12yocto-compat-layer: add --additional-layersPatrick Ohly
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. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12yocto-compat-layer: also determine tune flags for each taskPatrick Ohly
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. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-05yocto-compat-layer.py: Fix the signature validationMark Hatle
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-04-05yocto-compat-layer.py: Add --dependency argumentMark Hatle
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-04-05yocto-compat-layer.py: Add status for skipped itemsMark Hatle
If items were skipped because the dependencies could not be found, we want to record this was skipped so we can display it later. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-21scripts/yocto-compat-layer.py: Handle layer dependencies when testAníbal Limón
If some layer depends on other tries to find layer dependency, if the layer dependency isn't found avoid to test the layer and notice the user. Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-21scripts/yocto-compat-layer.py: Add option to disable layer autodiscoveryAníbal Limón
Sometimes there is a need to only analyze the layer specified by the command line, the new option -n will disable autodiscovery of layers and only will try to test specified layers. Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-21scripts/yocto-compat-layer.py: Make output log argument optionalAníbal Limón
Only create a log file when --output-log option is specified, since logger is dumping to stdout by default is better to let the user decide if a log needs to be created. [YOCTO #11160] Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-21scripts/yocto-compat-layer.py: Dump log to stdout instead of stderrAníbal Limón
The common unix tools uses stdout as standard for log output, by default python logging uses stderr if not stream is specified. [YOCTO #11160] Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-04yocto-compat-layer.py: Add script to YP Compatible Layer validationAníbal Limón
The yocto-compat-layer script serves as a tool to validate the alignament of a layer with YP Compatible Layers Programme [1], is based on an RFC sent to the ML to enable automatic testing of layers [2] that wants to be YP Compatible. The tool takes an layer (or set of layers) via command line option -l and detects what kind of layer is distro, machine or software and then executes a set of tests against the layer in order to validate the compatibility. The tests currently implemented are: common.test_readme: Test if a README file exists in the layer and isn't empty. common.test_parse: Test for execute bitbake -p without errors. common.test_show_environment: Test for execute bitbake -e without errors. common.test_signatures: Test executed in BSP and DISTRO layers to review doesn't comes with recipes that changes the signatures. bsp.test_bsp_defines_machines: Test if a BSP layers has machines configurations. bsp.test_bsp_no_set_machine: Test the BSP layer to doesn't set machine at adding layer. distro.test_distro_defines_distros: Test if a DISTRO layers has distro configurations. distro.test_distro_no_set_distro: Test the DISTRO layer to doesn't set distro at adding layer. Example of usage: $ source oe-init-build-env $ yocto-compat-layer.py LAYER_DIR [YOCTO #10596] [1] https://www.yoctoproject.org/webform/yocto-project-compatible-registration [2] https://lists.yoctoproject.org/pipermail/yocto-ab/2016-October/001801.html Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>