What’s new?
We’re happy to announce the release of v2.5.0, which includes a few new features as well as quality-of-life improvements and minor bug fixes. Here is the change log:
- Add Yocto variables renaming across a recipe file
- Add code suggestions for SRC_URI local files
- Add code suggestions for recipe names in variables (DEPENDS, RDEPENDS, etc)
- Add an option to prevent modification of .vscode/settings.json
- Add a command to start the taskexp GUI for a recipe
- Minor bug fixes
- Validate support for the latest Yocto Scarthgap LTS
- Remove deprecated shouldDeepExamine setting
- Refactor client/server packaging to remove deprecated dependencies
Recent Community Events
We also want to express our thanks to the amazing community that has been reporting issues and contributing to the project. We are also grateful for the warm exchanges we have had at recent events like Embedded World in Nuremberg and the Open Source Embedded Summit in Seattle. We’re hoping to see you at the upcoming Open Source Summit in Vienna, where we are likely going to present a talk on the extension. Make sure to keep posted.
Inspect recipe dependencies with taskexp
At one point, every Yocto developer has had to investigate a dependency chain within a Yocto image. This can be useful for:
- Removing an unwanted package from an image
- Identifying the source of a package in an image
- Understanding the impact of a change in a recipe
- Debugging a build failure
Poky provides several tools to help with this. One of them is taskexp
, which we chose to integrate into the extension since it is the most graphical one.
To use it, you can access the command “Bitbake: Examine recipe’s dependencies with taskexp” by right-clicking on a recipe or using the command palette. This will open a new terminal, which will start taskexp in a separate window. Taskexp will show the task dependencies for a recipe. It is quite verbose since it goes down to the task level; however, one can get a general view per recipe by focusing on the following:
- “do_populate_sysroot” task for build dependencies.
- “do_build” task for runtime dependencies.
Some other text-based tools provide more concise results, like oe-depends-dot
which analyses the .dot graph generated by bitbake -g
. There’s also a research project which produced an alternative visualization, you can find it under the MLinha.yocto-project-dependency-visualizer
extension. We are considering to integrate these tools in the future to provide more options to the user to inspect the dependencies.
More code suggestions in recipes
You can now get code suggestions (pressing Ctrl+Space
) for recipe names in a few places where they are used. We listed some of the most common variables like DEPENDS
and RDEPENDS
.
You can also find these suggestions for statements like inherit
and require
.
In the same fashion, local files will now be recommended inside the SRC_URI
variable.
Symbol renaming
This is yet another small and very intuitive feature that can save you some time.
You can now rename Bitbake variables through the contextual (right-click) menu. This feature is useful to quickly rename a variable across a recipe file. References to it inside bash functions and variables assignments will be updated as well.
For the next release, we plan on improving the accuracy of the renaming feature as well as forwarding renaming requests of the Bash and Python sections to the external extensions for those languages. This will allow you to rename locally defined variables and functions in those sections as well.
What’s next?
For v2.6.0 we are planning to address the more popular requests from the community. We identified that connecting to external bitbake servers could improve the flexibility of the extension to support more exotic setups. We’d also like to improve the rename feature introduced in this release to better integrate with Bash and Python sections of the recipe files.
Some more long term goals we’d like to address would be to make more of our VS Code specific features to the generic language server that can be already used with other IDEs like VIM. We’re also considering to add CodeLens actions but we still need to identify what new features would be most useful to present in that way. Other topics could be to integrate some other recipe dependency visualization tools and we are also watching the development of the new official layer setup tool that could provide a way to share VS Code settings.
Links and resources