openembedded-core.git/scripts/lib/compatlayer, branch thud

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

2017-09-21T10:34:08+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

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

yocto-compat-layer.py: make signature check code reusable

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

This moves the main content of test_signature into a helper
function. It can be reused by arbitrary tests that need to do
a before/after signature comparison. Long-term this might even
be useful in oeqa itself.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

yocto-compat-layer.py: allow README with suffix

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

It may be useful to append a suffix denoting the file format. For
example, README.rst is rendered differently when viewed on Github, and
also helps editors to switch to a mode more suitable for the format.

The tests uses a file pattern to find the README file(s) and treats
the one with the shortest name as the main one which must not be
empty.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

yocto-compat-layer.py: add test_world

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

"test_signatures" ignores wold build breakage for the sake of
reporting differences also when a world build is broken. Therefore we
need a dedicated test that a world build at least theoretically can
proceed without obvious parse time problems (dependencies, parse
errors, dangling .bbappends, etc.).

This is similar to the BSP test_machine_world. The difference is
that test_world doesn't change the MACHINE.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

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

2017-07-06T13:38:06+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.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

yocto-compat-layer.py: tolerate broken world builds during signature diff

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

The "test_signatures" test ignored a broken world build when getting
signatures, but the code which then tried to analyze a difference
found by the test didn't, which prevented printing the difference.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

yocto-compat-layer.py: avoid adding layers more than once

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

add_layer_dependencies() might get called more than once, or one of
the layer dependencies might already be present. The function should
not add layers again because doing so can cause warnings like:

  WARNING: Duplicate inclusion for .../meta-openembedded/meta-oe/conf/distro/include/meta_oe_security_flags.inc in .../meta-openembedded/meta-oe/conf/layer.conf

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

yocto-compat-layer: better handling of per-machine world build breakage

2017-04-12T22:55:53+00:00

It is fairly common that BSP layers enable recipes when choosing
machines from that layer without checking whether the recipe actually
builds in the current distro. That breaks "bitbake world", retrieving
signatures and thus the test_machine_signatures test.

It's better to let that test continue with the signatures that can be
retrieved and report the broken world build separately. Right now, the
new test_machine_world iterates over all machines. More elegant and
useful in combination with a (currently missing) selection of which
tests to run would be to generate one test instance per machine. But that
is not straightforward and has to wait.

The "-k" argument alone was not enough to proceed despite failures,
because bitbake then still returns a non-zero exit code. The existance
of the output file is taken as sign that the bitbake execution managed
was not fatally broken.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

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

2017-04-12T22:55:53+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.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

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

2017-04-12T14:02:14+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.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie