Our new dey-toolchain recipe was missing the logic needed to create the
"dey-version" file in the SDK's installation path. Move this logic from the
dey-image bbclass to a new bbclass meant exclusively for SDK logic, and inherit
it where needed. While at it, move other common SDK modifications to this
class.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This variable is used to determine the types of complementary packages included
in the SDK: dbg-pkgs, dev-pkgs, doc-pkgs, src-pkgs...
We added staticdev-pkgs to this variable back in Yocto 2.0 (45de4d6943), but
instead of appending it to the original list, we redefined it with its original
value ("dev-pkgs dbg-pkgs") plus "staticdev-pkgs".
However, the default value of SDKIMAGE_FEATURES in poky has changed over time:
* Starting in Yocto 2.3 (eb345ca720e5), doc-pkgs is included if
"api-documentation" is in DISTRO_FEATURES. We don't include this feature
by default, but if a customer were to include it manually, the doc
packages wouldn't get included in their custom SDKs.
* Starting in Yocto 2.7 (ba3aa5311291), bitbake changed the default
PACKAGE_DEBUG_SPLIT_STYLE value so debug packages get split in two: one
for binaries with debug symbols and another for the source code. In turn,
src-pkgs was added to the default SDKIMAGE_FEATURES so that SDKs wouldn't
change behavior, but since we overwrite the default value, we aren't
including src-pkgs in our SDKs, only dbg-pkgs.
* Any future changes would be ignored as well, which could potentially lead
to unexpected behavior.
Make sure we don't overwrite the default SDKIMAGE_FEATURES value to include
src-pkgs in our SDKs, as well as the optional doc-pkgs logic. Also, include
staticdev-pkgs in our recently created dey-toolchain recipe.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
For many DEY releases, we've been providing one SDK per image type, per
platform. In the case of graphical images, this was redundant for a few
reasons:
* Most of the SDK's contents were identical, save for the specific packages
in each image (qt, webkit, lvgl...) and their dependencies. With each SDK
occupying over 1.5 GiB, this results in a lot of storage space overhead
in our servers.
* For some images, namely webkit and lvgl images, their respective SDK
packages aren't necessary for the expected development use cases, so it's
perfectly possible to use the qt SDK instead.
Create a separate recipe for a general-use SDK. Said toolchain includes qt5/qt6
packages by default, except for headless platforms. The advantages of this are:
* We only provide one prebuilt SDK per platform, all with the same base
name. The SDK should cover most if not all of the expected development
use cases, and customers are still able to create their own custom SDKs
if needed.
* Having a separate recipe for the toolchain, not tied to a specific image
type, allows us to fine tune its contents without affecting images and
their recipes. With time, we can incorporate new packages as needed.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Gabriel Valcazar