Make "Devtool: Configure VSCode SDK" compatible with additional wrapper scripts and Docker-based environments

[yassibeh]

I confirm that the preview release works well — thank you!

That said, I really hope to see some enhancements to the "Devtool: Configure VSCode SDK" feature in future updates. It's honestly one of the best features I've seen for Yocto integration in VSCode — and it works flawlessly with standard Poky folders.

However, in custom setups like mine (where we use a cmdWrapper script to handle environment setup, Docker, and sourcing), the feature becomes nearly unusable because the wrapper is completely ignored. The tool seems hardwired for simple, flat Poky workspaces, and doesn't account for real-world custom environments.

Right now, I have to override launch.json, tasks.json, and ignore the extension’s automation — which defeats the whole purpose. I’d really love to see this feature made more flexible so it can integrate properly with wrapper-based or Dockerized environments.

Originally posted by @yassibeh in #419

[deribaucourt]

I think the extension is already compatible with the most common dockerized and wrapper-script based bitbake environments. For instance, kas and the crops/poky docker scripts work (even tested in our CI). But I do agree your use case made us discover that it still lacked compatibility with containers that must be kept open and the remote container extension. We'll keep track of this thanks to your other issues :).

[deribaucourt]

Probably linked to #416 and #415
Some things need to be adapted to work with the remote docker extension

[afreof]

Thank you for your feedback! Contributions to support setups beyond bare metal or fully transparent virtualization are welcome, and I'm happy to assist. You can find the relevant code here: ide_code.py.

My personal setup is a bare metal Linux machine using VSCode with the BitBake environment, without additional tooling or layers. As a result, it's challenging to anticipate the variety of setups others might use or how to test them automatically on Yocto's autobuilder. Your input and contributions can help improve support for different environments.

[yassibeh]

Hi Adrian (@afreof ),

I'm using devtool ide-sdk -i code in a custom Yocto setup where we rely on a wrapper script (setup-env) that not only sources oe-init-build-env, but also handles more advanced initialization steps (e.g., selecting configuration files, setting environment variables, launching Docker containers, etc.).

While the Yocto VSCode extension already supports this kind of wrapper logic through a configurable command wrapper, it seems that ide_code.py currently assumes a direct call to oe-init-build-env, which makes it harder to integrate in more complex, real-world setups like mine.

A possible solution could be to optionally support a wrapper script (e.g., via an environment variable or a metadata field), and fallback to the default behavior if not set. The idea would be something like:

if custom_wrapper:
oe_init = ". %s %s && ..." # wrapper script
else:
oe_init = ". oe-init-build-env %s && ..." # default

This is not a patch, just the general idea. I'd be happy to help contribute this in a clean and backward-compatible way. Would you be open to that?

Thanks again for your work - it's very appreciated!

[afreof]

This should be supported somehow by overriding the oe-init-build-env script in your layer. What I do also on minimal bare metal setups without containerization and more "advanced" ideas is, like that:

my-layer
    oe-init-build-env   # Copy of poky/oe-init-build-env with additional code, calls scripts/oe-buildenv-internal
    meta-my-stuff
    poky
        oe-init-build-env  # calls scripts/oe-buildenv-internal
        scripts/oe-buildenv-internal

The basic idea is to rename your setup-env to oe-init-build-env in a different folder than poky itself.

In general, it's challenging to review patches that introduce APIs which cannot be tested on Yocto's autobuilder. This approach is fragile, tends to break, and ultimately leads to dissatisfaction for both users and maintainers.

Therefore, I prefer sticking to officially supported minimums and keeping the bitbake setup simple. This means patches should focus on enhancing support for official development methods—such as bare metal development, VS Code with remote extensions, or Dev Containers—and leverage VS Code's advanced features (e.g., container management) to make virtualization as transparent as possible. This approach is also well-supported by devtool ide-sdk in general.

In contrast, creating custom setup environments that stack different technologies in non-standard ways is nearly impossible to support effectively. This is a general observation without specific knowledge of what your setup-env script actually does.