devtool workspace scan fails on older Yocto version

[joguy56]

When modifying a recipe using the --no-extract because of using an external directory, this directory is not listed in the devtool workspace.

Seems to be logic as it seems to be directly linked with the default sdk directory.

But, if devtool can manage external directories for modified recipes, I expect that the plugin does exactly the same, and is able to list modified recipes even if there were not extracted in the internal workspace.

It would be great to see it directly from vscode as if the usual sdk workspace was used !

[deribaucourt]

Thanks for this new issue report!
When viewing the devtool recipe name in the devtool side panel, we show the workspace reported by devtool status. I guess this is not right with the --no-extract option.
I'll have a look at reproducing it and try fixing it.
I'll let you know when I'm done.

[deribaucourt]

Hello @joguy56
Sorry for the delay, I finally had the time to test this. I did run devtool modify --no-extract busybox <some-external-dir> and the plugin did properly parse devtool status output to show it in the devtool workspaces tree view. However, make sure to rescan the project after you manually have input a devtool modify command.

We don't automatically re-scan the project because it is slow. We could add a file watcher in the workspace appends for that but I think manually pressing the "Bitbake: Rescan Project" is fine.

Let me know if re-starting a scan solved your issue.
Thanks!

[joguy56]

Hello @deribaucourt !

Indeed I see that the bbappend is pointing to the right sourctree. If I build the recipe from the devtool workspace wheel, I builds the right recipe at the external sourctree.

Now, if I click on the foam workspace, vscode don’t manage the fact that it is an external source tree, and it believes that it is a kind of docker container.

See the capture I get when I click on the workspace to open a new vscode instance inside it.

I also checked for a new recipe that the extension is not able to make a recipe appear in workspace panel if it was modified with an external path. From devtool point of view, the workspace is ok. If I try to add another time the recipe from extension, it says that the recipe is already in workspace. And I tried to rescan project, but no luck, the recipe is not seen as modified by the extension.

Please, let me know if you need any further informations.

Jonathan

[deribaucourt]

Could you provide more information on this error?

1. Does the path reported in this error message exist on your host?
2. Is VS Code susceptible to have permission errors when trying to access that path?
3. You are not using docker containers, right?
4. What is the output of "devtool status"?
5. You can turn on the extension's verbosity through the setting bitbake.loggingLevel, then please capture the logs in the Output -> BitBake window (next to terminals)

Thanks

[joguy56]

You can see that the recipe is correctly appended in workspace.

I could send you a log file but only in private please.

[deribaucourt]

So the path seen by devtool is /home/jguyot/work/rfsw/foam
While the path we try to open is /home/jguyot/work/esdk/sdk/workspace/sources/foam
However, looking at your bitbake-layers output, your .bbappend is located in /home/jguyot/work/esdk/sdk/workspace/appends/foam-interface_4.55.0.bbappend.

You seem to be using WSL on Windows from the look of the error message.
The extension is assuming that you are using mount points binding which you say is not the case. This will happen if we can't find the path we are lookgin for which makes sense because we are trying to open the wrong path. I'd like to understand why we resolve the wrong path when we are simply supposed to parse the devtool status output.

The debug log could help. I sent you my email.
Run a project rescan before capturing the output so that I can see what devtool status output we are parsing.

[deribaucourt]

Looking at your log, it seems our scan aborts because of the following error:

Executing Bitbake command with /bin/bash in /home/jguyot/work/rfsw/esdk/sdk: bitbake-getvar OVERRIDES
/bin/bash: bitbake-getvar: command not found
Failed to execute bitbake command: bitbake-getvar OVERRIDES
scanning of project is aborted: Error: Failed to execute bitbake command: bitbake-getvar OVERRIDES

It should have been reported to you in the "Terminal" view. This error is typical of using older Yocto versions. We try to align our support with the active Yocto versions defined on the official wiki: https://wiki.yoctoproject.org/wiki/Releases

The initial foam workspace is likely shown because at some point you created it through our GUI.

Could you confirm which Yocto version you are using?

[deribaucourt]

Closing this as a duplicate of #202