Introducing the v2.2 Release of the Yocto Project Extension for VS Code

Savoir-faire Linux is proud to announce the v2.2.0 release of the official Yocto Project extension for VS Code.

These developments were carried out as part of the investment provided by the Sovereign Tech Fund to the Yocto Project to improves the long-term sustainability of the project by attracting a new generation of developers.

The changelog for this release is our biggest one yet:

 - Add a new buildConfigurations settings array and status bar to manage multiple build configurations
 - Add a new command to scan a recipe
    - Generate definitions and completions for the variables from the recipe scan
    - Generate hovers with final values for the variables from the recipe scan
    - Automatically start the recipe scan instead of a general parse on save
    - Resolve variable expansions after the recipe scan for symbols resolution
 - Restore packaging for Windows, with a limited, stable feature set
 - Add a new command to start an interactive BitBake shell
 - Add support for colors, links and progress bars in the BitBake terminal
 - Add a reference provider for BitBake variables
 - Add new problem matchers for BitBake output
 - Suppress some false positives from embedded languages diagnostics
 - Automatically detect eSDK mode and deprecate previous option
 - Add definitions to overrides files
 - Add recipes suggestions for all commands if the project has been scanned
 - Add a command to open the WORKDIR of a recipe, allowing to inspect sources, builds and logs
 - Forward Python extension's import quick fixes into BitBake files
 - Stop resolving relative settings paths into absolute when invoking BitBake
 - Fix a bug where the settings were not properly updated on the language server
 - Various bug fixes and improvements

Some key metrics for this release:

• We’ve had more than 6,000 downloads since the last release.
• We pushed the number of CI tests to 194 (97 unit, 32 integration, 65 grammar).
• The CI+CD pipeline runs in approximately 10 minutes.
• We now provide 21 commands to schedule builds and manage devtool workspaces.

New feature: Managing multiple build/targets configurations

It is very frequent to develop multiple distros, images, or even machines at the same time in a Yocto Project workspace. Hence, being able to handle multiple build configurations within the VS Code extension was one of the most requested features by the community.

Users have as many ways to swap between configurations as they have configuration tools (local.conf, environment variables, and external tools like cqfd, crops, and kas). Our first idea was to use a common mechanism, which had to be a Yocto Project builtin to handle multiple configuration selections. Naturally, we picked the MULTICONFIG feature, which is documented under the appropriately named “Building Images for Multiple Targets Using Multiple Configurations” section of the documentation. It had also been suggested to us several times during our Yocto Project Summit 2023.11 presentation. However, after a very insightful discussion on the Yocto Project mailing list, it was argued that MULTICONFIG should be reserved only for single boards with multiple target coprocessors. The de facto way of handling multiple configurations is to use the same configuration tool in different build directories. This resulted in the feature we have today:

    "bitbake.buildConfigurations": [
        {
            "name": "Machine 1",
            "pathToBuildFolder": "${workspaceFolder}/build1"
        },
        {
            "name": "Machine 2",
            "pathToBuildFolder": "${workspaceFolder}/build2"
        }
    ]

In this new setting, users can write multiple configurations that will override the workspace properties, and it is not just limited to pathToBuildFolder. Users can override commandWrapper in each configuration as well. This is a lot more flexible than MULTICONFIG because users may pass specific configurations to external tools like CQFD build flavors or custom scripts. Once multiple build configurations have been defined, a toolbar will appear at the bottom right of VS Code, allowing you to select which one is active. All BitBake build and analyze commands will use the selected configuration henceforth. This UI design was inspired by the VS Code conventions documented in their extension guides and re-used across many examples, like the C/C++ or CMake extensions.

By the way, did you notice we now get colors and progress bars in the terminal?

New feature: Getting variable values from a recipe scan

What we really like about VS Code is how it can provide intuitive features that can easily be forgotten but add so much ease of use to a language. One of our favorite examples in the Yocto Project extension is completion suggestions for Yocto variables. Example: You just created a new .bbappend to add your custom .patch. You need to edit the FILES_EXTRAPATHS variable. Take the test; how would you write that variable’s name?

1. FILESEXTRAPATHS
2. FILES_EXTRAPATHS
3. FILES_EXTRA_PATHS
4. FILE_EXTRAPATH

Solution here. Well, with our extension, you wouldn’t have to remember this because when you start typing FILE, our extension will automatically suggest all the variables starting with that name and prevent parsing errors! It’s an almost invisible contribution, but once you are used to it, you can’t go back.

Enter today’s problem

The Yocto Project has complex variable expansion rules. There are overrides, append/remove operators, inherit/include statements, and even anonymous Python functions that can edit variable contents. Many language extensions provide the value of variables on hover. In our case, getting those results naively would mean calling bitbake-getvar, which can take several seconds to run. This would not be acceptable. Like we did for many features in our extensions, we had to design a cleverer way to provide this feature. We have replaced the ‘bitbake -p’ syntax check on save with the ‘bitbake -e’ command. This additional command gives us the full recipe environment with all variable values and definition history. Once a recipe has been scanned this way, we store the results and provide all variable values on hover and accurate definitions to the user. This results in a very powerful yet intuitive feature that previously required Yocto developers to compose custom commands and tedious grep operations.

Links and resources

Want to find out more about this ambitious VS Code extension for the Yocto Project?

• Download the extension from the VS Code marketplace
• Browse the code, report issues or contribute pull requests on our GitHub repository
• Read more about the initiative behind this project in our previous blog post
• Check out our presentation from the Yocto Project Summit 2023.11: