at the moment we start to migrate from a BSP to Torizon. To use a better development tools we tried Visual Studio Code. We have installed Visual Studio Code, Toradex Torizon Support, Remote - Containers and some other plugins for C++ and Python.
List of installed plugins:
If we now start “Torizon/C-C++: Create C/C++ application” like here we get the messsage:
The Remote-Containers extension
is required to develop C/C++
applications on Torizon
But from the installed plugins I see that it is installed.
Also we have tried python like here with “Torizon/Python: Create Python Application”. This works great. We create a python container and deploy it to the imx8.
What is the problem with C++?
Why can we build python but not c++ containers?
How can we send more debug informations?
We use : Linux DESKTOP-7LADUVD 18.104.22.168-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
I think I found a Problem:
If I’m connected to the wsl and install torizon in the wsl I get the “The Remote-Containers extension (ms-vscode-remote.remote-containers) is required to develop C/C++ applications on Torizon”.
But If I’m not connected to the wsl and install the Torizon-Plugin. I can create a “Torizon/C-C++: Create C/C++ application” in a windows folder (NOT WSL).
I think the problem is here:
If I try to use torizon in the with the wsl connection I don’t have the remote plugin. The remote plugin is only localy installed.
Is this by design?
Or how can I install the remote plugin in the wsl?
I have now understund it and I’m now able to work.
The trick is to NOT start the torizon in the WSL. You have to start the Development in a not connected Visual Studio Code.
Strange, but extrem cool. Good job guys.
Maybe it would be great to dokument this a little bit better.
Great to hear you got it squared away. I’ll pass the details along to the dev and tech pubs teams.
Yes, the VS Code when opened from WSL connects to the WSL environment, and some settings and extensions have to be configure explicitly by the user for the distro connected, that’s by design on VS Code so you can have different environments with different settings per WSL distro. You can select the extension and click on
Install in WSL: Ubuntu 20.04 (Here I’m using Ubuntu 20.04, but the label will be set to the name of distro which you have connected)
As WSL 2 runs a full Linux distro I see no problem running directly from the WSL 2 filesystem, but this has not been tested. On Windows we recommend to use extensions projects from Windows filesystem.
Thanks for the comment.
Yes there are some plugins wich can be installed in the Distro like Rust. Please take a look:
But there are also global plugins like: Remote - Containers ms-vscode-remote.remote-containers.
These plugins are enabled Global and don’t show up in the WSL2 because they are globaly enabled. PLease take a look:
I think the check that the check that “ms-vscode-remote.remote-containers” is wrong. Because you only look in the check in the local distro enabeled plugin list and not also in the global enabled plugin list. I think Toradex should correct this.
As Matheus has said while it is possible to run this all in the WSL 2 distro, it’s only designed/tested for the Windows filesystem. We’ll take a look but, for now please only use our extension from the Windows system as we designed it for.