From: Adrian Freihofer <adrian.freihofer@gmail.com>
To: openembedded-core@lists.openembedded.org
Cc: Adrian Freihofer <adrian.freihofer@siemens.com>
Subject: [PATCH v4 00/13] devtool ide plugin
Date: Sun, 27 Aug 2023 21:29:42 +0200 [thread overview]
Message-ID: <20230827193200.4083340-1-adrian.freihofer@siemens.com> (raw)
Changes in comparison to v3:
- Add workspace/attic fodler to vscode ignore lists.
Changes in comparison to v2:
- Fix the oe-selftests to run on a mchine without vscode installed
According to https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/
one of the proposed areas for development of the Yocto project is "VSCode IDE Integration - New developer tooling".
One aspect of this larger topic is helping application developers configure the IDE to work on a recipe's source code using Yocto's eSDK. This patchset provides a new devtool plugin (devtool ide) that does this fully automatically for recipes inheriting the cmake or the meson bbclass. Support for more programming languages and build tools may be added in the future.
Let's start with a brief introduction of how it looks like from a user's perspective.
Reference setup
---------------
$ . oe-init-build-env
Add the following layers to bblayers.conf file:
- meta
- meta-poky
- meta-yocto-bsp
- meta-selftest
Add the following to the local.conf
IMAGE_CLASSES += "image-combined-dbg"
IMAGE_GEN_DEBUGFS = "1"
IMAGE_FEATURES += "ssh-server-dropbear debug-tweaks"
IMAGE_INSTALL:append = "\
cmake-example-ptest \
meson-example-ptest \
gdbserver \
"
Working on a recipe
-------------------
Note for those who "hate cmake with passion": Replace cmake by meson in the following commands.
1. Add the recipe which should be modified to the workspace
$ devtool modify cmake-example
2. Build the eSDK. This provides all the host tools as well as an image which can be used on the target device.
Since everything is built with one bitbake command also all the debug symbols are expected to be consistent.
$ devtool ide cmake-example core-image-minimal
3. Install the image on the target device or simply use Qemu
$ runqemu
4. Start VSCode
$ code "$BUILDDIR/workspace/sources/cmake-example"
5. Work in VSCode, after installing the proposed plugins
Ctrl + Shift + p, cmake Select Configure Preset
Ctrl + Shift + p, cmake Build
6. Execute the unit tests on the host works with Qemu even for cross compiled test executables.
Ctrl + Shift + p, cmake Test
7. Remote debugging with GDB
Ctrl + Shift + p, Run Task --> install && deploy-target cmake-example
F5 (Debug configuration might be selected before)
8. Work on the recipes and call bitbake again to get the SDK updated.
Building the application by calling cmake (from the IDE) or by calling bitbake or by calling devtool build is expected to produce the exact same results. To make that possible, the devtool ide plugin is designed to configure the IDE to call cmake with the exact same configuration as used by bitbake when building the recipe. Unlike the eSDK, the goal here is clearly that there is no longer a separation between the SDK and the application development process. Regardless of which tool is called, the same source files are edited and the same o-files are generated and re-used.
Working with a SDK without a recipe
-----------------------------------
If devtool ide is called for a recipe named none or meta-ide-support the eSDK with its generic environment file gets generated.
In case of using VSCode and cmake in addition to the well known environment file a cmake-kit
https://vector-of-bool.github.io/docs/vscode-cmake-tools/kits.html is added to the User-Local Kits.
This allows to work with cmake calling the cross-toolchain out of VSCode or a shell with the environment file sourced.
Design
------
The goal of this implementation is to create a configuration for VSCode (or other IDEs) that allows to work on the code of a recipe completely independent from bitbake. bitbake is only called if the configuration or the whole SDK has to be regenerated. But bitbake should not need to be called while working in the IDE. This has two major advantages over calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example. These features are usable, which would not be the case if bitbake or devtool are called from within the IDE.
- It is much faster.
Supporting other IDEs
---------------------
Focus is currently VSCode. But a paramter "--ide=none" is already supported.
With this paramter passed, no VSCode specific config files are generated.
Instead, simple scripts are generated, which should be suitable for integration with other IDEs.
Testing
-------
Reasonable but not yet complete test coverage is provided by:
$ oe-selftest -r devtool.DevtoolIdeTests
What's next?
------------
- There is still a lot of room for improvement. But nonetheless, it provides a first implementation that could be integrated into the core, I think. Unfortunately there was no feedback on my RFC at https://lists.openembedded.org/g/openembedded-core/message/183819 so far.
- Support for more build-tools and programming languages as well as more IDEs should be possible. To prove the extendability 2 of both are already supported.
Adrian Freihofer (13):
vscode: add minimal configuration
cmake.bbclass: refactor cmake args
cmake.bbclass: cleanup spaces and tabs
cmake.bbclass: support qemu
devtool: new ide plugin
tests: add a C++ example recipe
cmake-example: workaround for pseudo breakeage
refactor: make multiprocess_launch callable without d
refactor: make strip_execs callable without d
devtool: refactor deploy-target
devtool: ide make deploy-target quicker
oe-selftest devtool: ide tests
docs: cover devtool ide
.gitignore | 2 +
.vscode/settings.json | 32 +
documentation/sdk-manual/extensible.rst | 97 +-
meta-selftest/recipes-test/cpp/.gitignore | 1 +
.../recipes-test/cpp/cmake-example.bb | 23 +
.../recipes-test/cpp/cmake-example/run-ptest | 10 +
.../recipes-test/cpp/cpp-example.inc | 24 +
.../recipes-test/cpp/files/CMakeLists.txt | 60 +
.../cpp/files/cpp-example-lib.cpp | 17 +
.../cpp/files/cpp-example-lib.hpp | 16 +
.../recipes-test/cpp/files/cpp-example.cpp | 16 +
.../recipes-test/cpp/files/meson.build | 34 +
.../cpp/files/test-cpp-example.cpp | 19 +
.../recipes-test/cpp/meson-example.bb | 17 +
.../recipes-test/cpp/meson-example/run-ptest | 10 +
meta/classes-global/staging.bbclass | 3 +-
meta/classes-recipe/cmake.bbclass | 70 +-
meta/lib/oe/package.py | 7 +-
meta/lib/oe/utils.py | 12 +-
meta/lib/oeqa/selftest/cases/devtool.py | 133 ++
scripts/lib/devtool/__init__.py | 5 +-
scripts/lib/devtool/deploy.py | 230 ++--
scripts/lib/devtool/ide.py | 1185 +++++++++++++++++
23 files changed, 1883 insertions(+), 140 deletions(-)
create mode 100644 .vscode/settings.json
create mode 100644 meta-selftest/recipes-test/cpp/.gitignore
create mode 100644 meta-selftest/recipes-test/cpp/cmake-example.bb
create mode 100644 meta-selftest/recipes-test/cpp/cmake-example/run-ptest
create mode 100644 meta-selftest/recipes-test/cpp/cpp-example.inc
create mode 100644 meta-selftest/recipes-test/cpp/files/CMakeLists.txt
create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.cpp
create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.hpp
create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example.cpp
create mode 100644 meta-selftest/recipes-test/cpp/files/meson.build
create mode 100644 meta-selftest/recipes-test/cpp/files/test-cpp-example.cpp
create mode 100644 meta-selftest/recipes-test/cpp/meson-example.bb
create mode 100644 meta-selftest/recipes-test/cpp/meson-example/run-ptest
create mode 100755 scripts/lib/devtool/ide.py
--
2.41.0
next reply other threads:[~2023-08-27 19:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-27 19:29 Adrian Freihofer [this message]
2023-08-27 19:29 ` [PATCH v4 01/13] vscode: add minimal configuration Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 02/13] cmake.bbclass: refactor cmake args Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 03/13] cmake.bbclass: cleanup spaces and tabs Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 04/13] cmake.bbclass: support qemu Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 05/13] devtool: new ide plugin Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 06/13] tests: add a C++ example recipe Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 07/13] cmake-example: workaround for pseudo breakeage Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 08/13] refactor: make multiprocess_launch callable without d Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 09/13] refactor: make strip_execs " Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 10/13] devtool: refactor deploy-target Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 11/13] devtool: ide make deploy-target quicker Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 12/13] oe-selftest devtool: ide tests Adrian Freihofer
2023-08-27 19:29 ` [PATCH v4 13/13] docs: cover devtool ide Adrian Freihofer
2023-08-30 14:36 ` [OE-core] [PATCH v4 00/13] devtool ide plugin Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230827193200.4083340-1-adrian.freihofer@siemens.com \
--to=adrian.freihofer@gmail.com \
--cc=adrian.freihofer@siemens.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox