linux/poky.git/scripts/lib/devtool, branch styhead

devtool: ide-sdk remove the plugin from eSDK installer

2025-02-03T14:24:37+00:00

The ide-sdk command bootstraps the SDK from the bitbake environment before the IDE configuration is generated. In the case of the eSDK installer, the bootstrapping is performed during the installation of the eSDK installer. Running the ide-sdk plugin from an eSDK installer based setup would require skipping the bootstrapping and probably taking some other differences into account when generating the IDE configurations. This would be possible. But it will probably never be implemented, as running devtool ide-sdk directly from the bitbake environment is much more flexible. Also, some of the recent improvements that have made it into the core have the potential to make the eSDK installer obsolete at some point in the future: - bitbake-layers create-layers-setup replicates the layers - bitbake-config-build replicates the build configuration - The new sstate mirror features replicate the sstate - bblock locks the sstate more flexible than the eSDK installer - devtool ide-sdk bootstraps the SDK directly from the bitbake environment. The same environment-setup... file is provided with --mode=shared. The devtool modify based workflow is supported since always by devtool and also the default --mode of devtool ide-sdk. These functions essentially cover what the eSDK installer does without a need for the current implementation of the eSDK installer and the populate_sdk_ext, which is hard to maintain and takes a lot of time to build. This means that instead of making the ide-sdk plugin compatible with the eSDK installer, we should rather replace the current implementation of the eSDK installer and populate_sdk_ext with an implementation that can replicate a normal bitbake environment in a convenient way where the ide-sdk plugin also just works without additional complexity. (From OE-Core rev: a5e7ff4424a68335fc768e49a232a58011a5b160) Signed-off-by: Adrian Freihofer Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

devtool: ide-sdk recommend DEBUG_BUILD

2025-02-03T14:24:37+00:00

The debug_build_config function was never called. Compiling with debug optimized compiler flags was not working. Even with the --debug-build-config flag set, the build configuration from the recipe was used. The devtool ide-sdk --debug-build-config approach didn't work very well anyway. The problem is that changing the bbappend file doesn't work while bitbake uses the bbappend file. As a workaround, it would be possible to parse the recipe, get DEBUG_BUILD and the path to the append file, exit tinfoil, change the bbappend file, reopen tinfoil and do what ide-sdk is supposed to do. Such an implementation would be complicated and slow. Therefore, the code that was originally supposed to implement this is removed from ide-sdk and the new --debug-build function of devtool modify is used instead. Additionally, a hint should be given on how to manually add DEBUG_BUILD = '1' to bbappend. This is compatible with the VSCode Bitbake plug-in, which does not support this parameter anyway. (From OE-Core rev: 8753ddc7a42a09eec9b12af97b2b511b2970d83c) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

devtool: ide-sdk sort cmake preset

2025-02-03T14:24:37+00:00

Sort the keys of the generated CMakeUserPreset.json file to make it easier to search and compare. (From OE-Core rev: ad633eb3b90adb1087609c97ab8dc83ca0f08ad2) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

devtool: modify support debug-builds

2025-02-03T14:24:37+00:00

Add a new option --debug-builds to automatically add DEBUG_BUILD = “1” to the bbappend file of this recipe. This is especially useful when invoking devtool modify before invoking devtool ide-sdk to perform a remote debugging session. (From OE-Core rev: c1bea1549d3bc47845b7c23158d48fad8e17277e) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

devtool: remove obsolete SRCTREECOVEREDTASKS handling

2024-09-04T11:38:44+00:00

devtool modify generates a bbappend for kernel recipes which contains: SRCTREECOVEREDTASKS="\ do_fetch \ do_kernel_checkout \ do_kernel_configcheck \ do_unpack \ do_validate_branches \ " do_patch[noexec] = "1" If the linux-yocto kernel is used, this is redundant. The linux-yocto.bbclass already does the same: linux-yocto sets SRCTREECOVEREDTASKS to SRCTREECOVEREDTASKS="\ do_fetch \ do_kernel_checkout \ do_kernel_configcheck \ do_patch \ do_unpack \ do_validate_branches \ " Also the do_patch[noexec] is redundant because the purpose of SRCTREECOVEREDTASKS is to delete these tasks if the externalsrc.bbclass is used. The default value of SRCTREECOVEREDTASKS initialized in externalsrc.bbclass is: SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch" This is fine for kernels which do not inherit the linux-yocto.bbclass. The code in devtool modify is redundant and therefore removed. (From OE-Core rev: 94ff1be36a1eeef7ddceb4fcf20425a03cd052de) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

devtool: modify kernel adds append twice

2024-09-04T11:38:44+00:00

Drop the redundant generation of the do_configure:append section for the kernel. The same append is generated twice: if bb.data.inherits_class('kernel', rd): f.write('\ndo_configure:append() {\n' ' cp ${B}/.config ${S}/.config.baseline\n' ' ln -sfT ${B}/.config ${S}/.config.new\n' '}\n') KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= "true" KCONFIG_CONFIG_ROOTDIR ??= "${B}" if rd.getVarFlag('do_menuconfig', 'task'): f.write('\ndo_configure:append() {\n' ' if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then\n' ' cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline\n' ' ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new\n' ' fi\n' '}\n') In contradiction to the first code block the second code block considers the variables which is correct. (From OE-Core rev: b0733c440e861ed7bf70efdd9b7a73afb4701218) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

devtool/upgrade: rename RECIPE_UPDATE_EXTRA_TASKS -> RECIPE_UPGRADE_EXTRA_TASKS

2024-08-03T06:56:10+00:00

'UPDATE' as a name is somewhat unfortunate as the variable is intended only for the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation. (From OE-Core rev: 4467aa0661e233f44c4ce029428c67d88fccfc07) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool/upgrade: use PN instead of BPN for naming newly created upgraded recipes

2024-07-22T15:53:06+00:00

BPN isn't correct, as it is set to 'cmake' when 'cmake-native' is being upgraded (or libva for libva-initial etc.) (From OE-Core rev: e634316547f86ce5662fa4899440a5af1047d494) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

recipeutils/get_recipe_upgrade_status: group recipes when they need to be upgraded together

2024-07-22T15:53:06+00:00

This will allow 'lockstep upgrades' of such recipes, improving success rates in automated version updating process. devtool check-upgrade-status now prints: These recipes need to be upgraded together { glib-2.0 2.80.2 2.80.4 Anuj Mittal glib-2.0-initial 2.80.2 2.80.4 Anuj Mittal } These recipes need to be upgraded together { util-linux 2.39.3 2.40.2 Chen Qi util-linux-libuuid 2.39.3 2.40.2 Chen Qi } These recipes need to be upgraded together { cmake 3.29.3 3.30.0 Unassigned cmake-native 3.29.3 3.30.0 Unassigned } etc. (From OE-Core rev: 7874aea5c62be3e8dbd19e04fce5389c5ed7aab6) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

lib/oe/recipeutils: return a dict in get_recipe_upgrade_status() instead of a tuple

2024-07-22T15:53:06+00:00

Putting various things in a tuple is an anti-pattern of sorts, as the consumers have to unpack it into local variables for readability, or access items directly with indexes, which makes code pretty much unreadable. (From OE-Core rev: e86aa26d209eb9809198f6dd40cd058366318e3d) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie