A few variable dependencies were incorrect from the SPDX tasks, which
prevented rebuilds from occurring, or caused them to occur when they
should not.
(From OE-Core rev: 38a5dd136b3a3713e63d23598011efe1c4b0f459)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SPDX code makes heavy use of python classes. While this works very
well, the bitbake dependency parser is unable to understand how to deal
with them, and thus changes to the class code do not cause rebuilds to
occur. To correct this, add the library files that include SPDX code as
file checksums for the SPDX tasks. If this method works well for SPDX,
we will look at implementing something similar in the bitbake dependency
parser that should allow correct checksums without having to explicitly
add them to each class.
(From OE-Core rev: 6ac3033b77a0d1f7ab15801c5c65931adede3923)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, "tarball" sdk based recipes don't generate SPDX manifests as they
don't include the rootfs generation classes. Split the SPDX 3.0 image class into
two so the SDK components can be included where needed.
To do this, introduce an SDK_CLASSES variable similar to IMAGE_CLASSES which
the SDK code can use.
Migrate testsdk usage to this.
Also move the image/sdk spdx classes to classes-recipe rather than the general classes
directory since they'd never be included on a global level.
For buildtools-tarball, it has its own testsdk functions so disable the class there as
a deferred inherit would overwrite it.
(From OE-Core rev: 662396533177b72cc1d83e95841b27f7e42dcb20)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
