summaryrefslogtreecommitdiffstats
path: root/scripts/lib
diff options
context:
space:
mode:
authorAdrian Freihofer <adrian.freihofer@gmail.com>2025-01-14 00:39:09 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2025-01-20 13:38:59 +0000
commit096dbb79928cbbb4e2fb8203582a025b44d4576c (patch)
tree1274418059b1cea6731b52f20bdef454a928d5bb /scripts/lib
parent9059981930ea798ef266a2cfb9e0705ebd81826b (diff)
downloadpoky-096dbb79928cbbb4e2fb8203582a025b44d4576c.tar.gz
devtool: ide-sdk remove the plugin from eSDK installer
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: 177aa72b37f2061ff3311ec5dbb33aa56a5ba006) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'scripts/lib')
-rwxr-xr-xscripts/lib/devtool/ide_sdk.py9
1 files changed, 9 insertions, 0 deletions
diff --git a/scripts/lib/devtool/ide_sdk.py b/scripts/lib/devtool/ide_sdk.py
index 42ac20c654..f8cf65f4a8 100755
--- a/scripts/lib/devtool/ide_sdk.py
+++ b/scripts/lib/devtool/ide_sdk.py
@@ -927,6 +927,15 @@ def ide_setup(args, config, basepath, workspace):
927def register_commands(subparsers, context): 927def register_commands(subparsers, context):
928 """Register devtool subcommands from this plugin""" 928 """Register devtool subcommands from this plugin"""
929 929
930 # The ide-sdk command bootstraps the SDK from the bitbake environment before the IDE
931 # configuration is generated. In the case of the eSDK, the bootstrapping is performed
932 # during the installation of the eSDK installer. Running the ide-sdk plugin from an
933 # eSDK installer-based setup would require skipping the bootstrapping and probably
934 # taking some other differences into account when generating the IDE configurations.
935 # This would be possible. But it is not implemented.
936 if context.fixed_setup:
937 return
938
930 global ide_plugins 939 global ide_plugins
931 940
932 # Search for IDE plugins in all sub-folders named ide_plugins where devtool seraches for plugins. 941 # Search for IDE plugins in all sub-folders named ide_plugins where devtool seraches for plugins.