[PATCH 0/6] devtool: ide: Improve VSCode support

[PATCH 0/6] devtool: ide: Improve VSCode support

[Enguerrand de Ribaucourt]

These patches improve the VSCode support in devtool ide-sdk from
Adrian Freihofer.

I added a generic C++ configuration for the VScode
extension while awaiting for autotools support.

A refactoring is proposed for the meson class. Without absolute compiler
paths, the linter inside VSCode will not be able to find the
cross-compiler. Let me know if you have any concerns about this
refactoring.

The other bug fixes are relatively minor and make the tool work for some edge
cases.

[PATCH 1/6] devtool: ide: Fix topdir exception for fallback mode

[Enguerrand de Ribaucourt]

An exception was raised because we did not have the topdir attribute
which was used in fallback mode (non cmake/meson recipes).

Already in the merge queue in Adrian's latest patches.
---
 scripts/lib/devtool/ide_sdk.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/lib/devtool/ide_sdk.py b/scripts/lib/devtool/ide_sdk.py
index 3986dc1436a..db2e95616be 100755
--- a/scripts/lib/devtool/ide_sdk.py
+++ b/scripts/lib/devtool/ide_sdk.py
@@ -366,6 +366,7 @@ class RecipeModified:
         self.target_arch = recipe_d.getVar('TARGET_ARCH')
         self.topdir = recipe_d.getVar('TOPDIR')
         self.workdir = os.path.realpath(recipe_d.getVar('WORKDIR'))
+        self.topdir = os.path.realpath(recipe_d.getVar('TOPDIR'))
 
         self.__init_exported_variables(recipe_d)
 
-- 
2.34.1

Re: [PATCH 1/6] devtool: ide: Fix topdir exception for fallback mode

[adrian.freihofer]

On Thu, 2024-02-15 at 18:04 +0100, Enguerrand de Ribaucourt wrote:
> An exception was raised because we did not have the topdir attribute
> which was used in fallback mode (non cmake/meson recipes).
> 
> Already in the merge queue in Adrian's latest patches.
> ---
>  scripts/lib/devtool/ide_sdk.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/lib/devtool/ide_sdk.py
> b/scripts/lib/devtool/ide_sdk.py
> index 3986dc1436a..db2e95616be 100755
> --- a/scripts/lib/devtool/ide_sdk.py
> +++ b/scripts/lib/devtool/ide_sdk.py
> @@ -366,6 +366,7 @@ class RecipeModified:
>          self.target_arch = recipe_d.getVar('TARGET_ARCH')
>          self.topdir = recipe_d.getVar('TOPDIR')
>          self.workdir = os.path.realpath(recipe_d.getVar('WORKDIR'))
> +        self.topdir = os.path.realpath(recipe_d.getVar('TOPDIR'))

I think this patch is not needed. Two lines above the variable is
already initialized.
Some time ago there was an exception but it is fixes on master-next
already.

>  
>          self.__init_exported_variables(recipe_d)
>  

[PATCH 2/6] devtool: ide_sdk: Use bitbake's python3 for generated scripts

[Enguerrand de Ribaucourt]

The generated scripts use the sys.path configuration found inside
bitbake. It can be a different python version than the one used on the
host through the IDE.

For instance, when running the generated script
deploy_target_cmake-example-core2-64 from an eSDK generated on another
machine, I got the following exception:
    AssertionError: SRE module mismatch

We need to match the sys.executable to the sys.path.
---
 scripts/lib/devtool/ide_sdk.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/ide_sdk.py b/scripts/lib/devtool/ide_sdk.py
index db2e95616be..a82ab572998 100755
--- a/scripts/lib/devtool/ide_sdk.py
+++ b/scripts/lib/devtool/ide_sdk.py
@@ -751,7 +751,7 @@ class RecipeModified:
         does not need to start a bitbake server. All information from tinfoil
         is hard-coded in the generated script.
         """
-        cmd_lines = ['#!/usr/bin/env python3']
+        cmd_lines = ['#!%s' % str(sys.executable)]
         cmd_lines.append('import sys')
         cmd_lines.append('devtool_sys_path = %s' % str(sys.path))
         cmd_lines.append('devtool_sys_path.reverse()')
-- 
2.34.1

[PATCH 3/6] devtool: code: Add source mapping for debug source files

[Enguerrand de Ribaucourt]

When launching the debug configuration, the source files from the debug
rootfs were openened in the editor instead of the local workspace files.
We add an exception to properly map them to the file being developed and
compiled by the IDE integration. This also more closely matches what the
user would expect compared to native development.

This is also true for the devtool fallback mode.
---
 scripts/lib/devtool/ide_plugins/ide_code.py | 1 +
 scripts/lib/devtool/ide_sdk.py              | 1 +
 2 files changed, 2 insertions(+)

diff --git a/scripts/lib/devtool/ide_plugins/ide_code.py b/scripts/lib/devtool/ide_plugins/ide_code.py
index b2193130d2e..c063b7d0590 100644
--- a/scripts/lib/devtool/ide_plugins/ide_code.py
+++ b/scripts/lib/devtool/ide_plugins/ide_code.py
@@ -234,6 +234,7 @@ class IdeVSCode(IdeBase):
         if gdb_cross_config.image_recipe.rootfs_dbg:
             launch_config['additionalSOLibSearchPath'] = modified_recipe.solib_search_path_str(
                 gdb_cross_config.image_recipe)
+            src_file_map[os.path.join("/usr/src/debug", modified_recipe.pn, modified_recipe.pv)] = "${workspaceFolder}"
             src_file_map["/usr/src/debug"] = os.path.join(
                 gdb_cross_config.image_recipe.rootfs_dbg, "usr", "src", "debug")
         else:
diff --git a/scripts/lib/devtool/ide_sdk.py b/scripts/lib/devtool/ide_sdk.py
index a82ab572998..1e36f2b2093 100755
--- a/scripts/lib/devtool/ide_sdk.py
+++ b/scripts/lib/devtool/ide_sdk.py
@@ -356,6 +356,7 @@ class RecipeModified:
             'PACKAGE_DEBUG_SPLIT_STYLE')
         self.path = recipe_d.getVar('PATH')
         self.pn = recipe_d.getVar('PN')
+        self.pv = recipe_d.getVar('PV')
         self.recipe_sysroot = os.path.realpath(
             recipe_d.getVar('RECIPE_SYSROOT'))
         self.recipe_sysroot_native = os.path.realpath(
-- 
2.34.1

Re: [PATCH 3/6] devtool: code: Add source mapping for debug source files

[adrian.freihofer]

On Thu, 2024-02-15 at 18:04 +0100, Enguerrand de Ribaucourt wrote:
> When launching the debug configuration, the source files from the
> debug
> rootfs were openened in the editor instead of the local workspace
> files.
> We add an exception to properly map them to the file being developed
> and
> compiled by the IDE integration. This also more closely matches what
> the
> user would expect compared to native development.
> 
> This is also true for the devtool fallback mode.

This sounds a little bit unexpected to me. With devtool deploy-target
the binaries which are copied to the target device have still the
absolute rpath from the real build host. The are not packaged.

I would expect something like this when a packaged binary would be
debugged. But I'm not sure if that would make sense and should be
supported.

> ---
>  scripts/lib/devtool/ide_plugins/ide_code.py | 1 +
>  scripts/lib/devtool/ide_sdk.py              | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/scripts/lib/devtool/ide_plugins/ide_code.py
> b/scripts/lib/devtool/ide_plugins/ide_code.py
> index b2193130d2e..c063b7d0590 100644
> --- a/scripts/lib/devtool/ide_plugins/ide_code.py
> +++ b/scripts/lib/devtool/ide_plugins/ide_code.py
> @@ -234,6 +234,7 @@ class IdeVSCode(IdeBase):
>          if gdb_cross_config.image_recipe.rootfs_dbg:
>              launch_config['additionalSOLibSearchPath'] =
> modified_recipe.solib_search_path_str(
>                  gdb_cross_config.image_recipe)
> +            src_file_map[os.path.join("/usr/src/debug",
> modified_recipe.pn, modified_recipe.pv)] = "${workspaceFolder}"
>              src_file_map["/usr/src/debug"] = os.path.join(
>                  gdb_cross_config.image_recipe.rootfs_dbg, "usr",
> "src", "debug")
>          else:
> diff --git a/scripts/lib/devtool/ide_sdk.py
> b/scripts/lib/devtool/ide_sdk.py
> index a82ab572998..1e36f2b2093 100755
> --- a/scripts/lib/devtool/ide_sdk.py
> +++ b/scripts/lib/devtool/ide_sdk.py
> @@ -356,6 +356,7 @@ class RecipeModified:
>              'PACKAGE_DEBUG_SPLIT_STYLE')
>          self.path = recipe_d.getVar('PATH')
>          self.pn = recipe_d.getVar('PN')
> +        self.pv = recipe_d.getVar('PV')
>          self.recipe_sysroot = os.path.realpath(
>              recipe_d.getVar('RECIPE_SYSROOT'))
>          self.recipe_sysroot_native = os.path.realpath(

[PATCH 4/6] devtool: ide: vscode: Configure read-only files

[Enguerrand de Ribaucourt]

When debugging or browsing files, the user may fall into external
sources from other packages in the sysroot or dbg-rootfs. Modifying them
will only lead to confusion since they will be overwritten by Yocto. The
user should open them in a separate devtool modify session if they want
to make changes. Meanwhile, we should prevent write access to them.
---
 scripts/lib/devtool/ide_plugins/ide_code.py | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/devtool/ide_plugins/ide_code.py b/scripts/lib/devtool/ide_plugins/ide_code.py
index c063b7d0590..7b683c74086 100644
--- a/scripts/lib/devtool/ide_plugins/ide_code.py
+++ b/scripts/lib/devtool/ide_plugins/ide_code.py
@@ -125,7 +125,7 @@ class IdeVSCode(IdeBase):
         settings_dict["cmake.configureOnOpen"] = True
         settings_dict["cmake.sourceDirectory"] = modified_recipe.real_srctree
 
-    def vscode_settings(self, modified_recipe):
+    def vscode_settings(self, modified_recipe, image_recipe):
         files_excludes = {
             "**/.git/**": True,
             "**/oe-logs/**": True,
@@ -138,9 +138,16 @@ class IdeVSCode(IdeBase):
             "**/oe-workdir/**",
             "**/source-date-epoch/**"
         ]
+        files_readonly = {
+            modified_recipe.recipe_sysroot + '/**': True,
+            modified_recipe.recipe_sysroot_native + '/**': True,
+        }
+        if image_recipe.rootfs_dbg is not None:
+            files_readonly[image_recipe.rootfs_dbg + '/**'] = True
         settings_dict = {
             "files.watcherExclude": files_excludes,
             "files.exclude": files_excludes,
+            "files.readonlyInclude": files_readonly,
             "python.analysis.exclude": python_exclude
         }
         self.__vscode_settings_cmake(settings_dict, modified_recipe)
@@ -425,7 +432,7 @@ class IdeVSCode(IdeBase):
             self.vscode_tasks_fallback(args, modified_recipe)
 
     def setup_modified_recipe(self, args, image_recipe, modified_recipe):
-        self.vscode_settings(modified_recipe)
+        self.vscode_settings(modified_recipe, image_recipe)
         self.vscode_extensions(modified_recipe)
         self.vscode_c_cpp_properties(modified_recipe)
         if args.target:
-- 
2.34.1

[PATCH 5/6] meson: use absolute cross-compiler paths

[Enguerrand de Ribaucourt]

Among the files generated by meson is compile_commands.json. It is not
used by bitbake during the build. However, if the devtool workspace is
opened inside an IDE, that IDE can use compile_commands.json to
configure linting and code completion. This is notably relied on by the
new devtool ide-sdk command.

The problem is that the IDE using compile_commands.json does not know
the $PATH set-up by bitbake, so it won't find the compiler. This results
in linting errors, like missing headers. We can fix this by expliciting
the absolute compiler paths in meson.cross.

The compile_commands.json specification expressly states:
"All paths specified in the command or file fields must be either
absolute or relative to this directory."
Link: https://clang.llvm.org/docs/JSONCompilationDatabase.html

An alternative way to implement this is to directly change CXX inside
bitbake.conf to make all recipes use absolute compiler paths.Since this
would affect all recipes, so I would like to have the maintainers'
opinion on this. It could make sense to use absolute compiler paths for
all toolchain binaries, we already do so for the sysroot
TOOLCHAIN_OPTIONS.

Discussions have been opened with meson/ninja maintainers to implement
this at their level:
 - https://github.com/ninja-build/ninja/issues/2383
 - https://github.com/mesonbuild/meson/issues/12834
These tools have even less information on the environment so it makes
sense for Yocto to provide the absolute paths.
---
 meta/classes-recipe/meson-routines.bbclass | 6 ++++++
 meta/classes-recipe/meson.bbclass          | 7 +++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/meson-routines.bbclass b/meta/classes-recipe/meson-routines.bbclass
index a944a8fff1c..9925465ed8f 100644
--- a/meta/classes-recipe/meson-routines.bbclass
+++ b/meta/classes-recipe/meson-routines.bbclass
@@ -10,6 +10,12 @@ def meson_array(var, d):
     items = d.getVar(var).split()
     return repr(items[0] if len(items) == 1 else items)
 
+def meson_array_abspath(var, d):
+    import shutil
+    items = d.getVar(var).split()
+    items[0] = shutil.which(items[0]) or items[0]
+    return repr(items[0] if len(items) == 1 else items)
+
 # Map our ARCH values to what Meson expects:
 # http://mesonbuild.com/Reference-tables.html#cpu-families
 def meson_cpu_family(var, d):
diff --git a/meta/classes-recipe/meson.bbclass b/meta/classes-recipe/meson.bbclass
index a849e872976..d8496854df4 100644
--- a/meta/classes-recipe/meson.bbclass
+++ b/meta/classes-recipe/meson.bbclass
@@ -64,10 +64,13 @@ addtask write_config before do_configure
 do_write_config[vardeps] += "CC CXX AR NM STRIP READELF OBJCOPY CFLAGS CXXFLAGS LDFLAGS RUSTC RUSTFLAGS EXEWRAPPER_ENABLED"
 do_write_config() {
     # This needs to be Py to split the args into single-element lists
+    # The generated compile_commands.json file can be used by external IDEs
+    # which do not know the $PATH set-up by bitbake. They need the absolute
+    # compiler paths.
     cat >${WORKDIR}/meson.cross <<EOF
 [binaries]
-c = ${@meson_array('CC', d)}
-cpp = ${@meson_array('CXX', d)}
+c = ${@meson_array_abspath('CC', d)}
+cpp = ${@meson_array_abspath('CXX', d)}
 cython = 'cython3'
 ar = ${@meson_array('AR', d)}
 nm = ${@meson_array('NM', d)}
-- 
2.34.1

[PATCH 6/6] devtool: code: Provide a generic C++ configuration

[Enguerrand de Ribaucourt]

By default, the cpptools VSCode extension will use the host's headers
and flags for linting. This results in a lot of include errors and
misleading definitions. Even though this generic configuration doesn't
include all the depenendencies, it is a proper fallback for recipe
classes we do not accurately cover, with at least the right sysroot.

Additionally, ide-sdk automatically detects and provides a launch.json
configuration for autotools recipes so we should recommend the C++
extensions for them.

If the recipe is of another class (like Python), then the configuration
will be generated but probably useless to the user. We'd need a mecanism
to know if the recipe contains C/C++ but I'm not aware of any
class-agnostic way to do it.
---
 scripts/lib/devtool/ide_plugins/ide_code.py | 25 ++++++++++++---------
 scripts/lib/devtool/ide_sdk.py              |  3 +++
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/scripts/lib/devtool/ide_plugins/ide_code.py b/scripts/lib/devtool/ide_plugins/ide_code.py
index 7b683c74086..51cf2c8a736 100644
--- a/scripts/lib/devtool/ide_plugins/ide_code.py
+++ b/scripts/lib/devtool/ide_plugins/ide_code.py
@@ -157,31 +157,33 @@ class IdeVSCode(IdeBase):
         IdeBase.update_json_file(
             self.dot_code_dir(modified_recipe), settings_file, settings_dict)
 
+    def __vscode_extensions_generic(self, modified_recipe, recommendations):
+        recommendations += [
+            "ms-vscode.cpptools",
+            "ms-vscode.cpptools-extension-pack",
+            "ms-vscode.cpptools-themes"
+        ]
+
     def __vscode_extensions_cmake(self, modified_recipe, recommendations):
         if modified_recipe.build_tool is not BuildTool.CMAKE:
             return
         recommendations += [
             "twxs.cmake",
-            "ms-vscode.cmake-tools",
-            "ms-vscode.cpptools",
-            "ms-vscode.cpptools-extension-pack",
-            "ms-vscode.cpptools-themes"
+            "ms-vscode.cmake-tools"
         ]
 
     def __vscode_extensions_meson(self, modified_recipe, recommendations):
         if modified_recipe.build_tool is not BuildTool.MESON:
             return
         recommendations += [
-            'mesonbuild.mesonbuild',
-            "ms-vscode.cpptools",
-            "ms-vscode.cpptools-extension-pack",
-            "ms-vscode.cpptools-themes"
+            'mesonbuild.mesonbuild'
         ]
 
     def vscode_extensions(self, modified_recipe):
         recommendations = []
         self.__vscode_extensions_cmake(modified_recipe, recommendations)
         self.__vscode_extensions_meson(modified_recipe, recommendations)
+        self.__vscode_extensions_generic(modified_recipe, recommendations)
         extensions_file = 'extensions.json'
         IdeBase.update_json_file(
             self.dot_code_dir(modified_recipe), extensions_file, {"recommendations": recommendations})
@@ -194,8 +196,11 @@ class IdeVSCode(IdeBase):
             properties_dict["configurationProvider"] = "ms-vscode.cmake-tools"
         elif modified_recipe.build_tool is BuildTool.MESON:
             properties_dict["configurationProvider"] = "mesonbuild.mesonbuild"
-        else:  # no C/C++ build
-            return
+        else:  
+            # Provide a generic linting configuration
+            # We provide a C++ configuration with the proper sysroot
+            properties_dict["compilerPath"] = os.path.join(modified_recipe.staging_bindir_toolchain, modified_recipe.cxx.split()[0])
+            properties_dict["compilerArgs"] = modified_recipe.cxx.split()[1:]
 
         properties_dicts = {
             "configurations": [
diff --git a/scripts/lib/devtool/ide_sdk.py b/scripts/lib/devtool/ide_sdk.py
index 1e36f2b2093..c82b150a83e 100755
--- a/scripts/lib/devtool/ide_sdk.py
+++ b/scripts/lib/devtool/ide_sdk.py
@@ -345,6 +345,7 @@ class RecipeModified:
         self.base_libdir = recipe_d.getVar('base_libdir')
         self.bblayers = recipe_d.getVar('BBLAYERS').split()
         self.bpn = recipe_d.getVar('BPN')
+        self.cxx = recipe_d.getVar('CXX')
         self.d = recipe_d.getVar('D')
         self.fakerootcmd = recipe_d.getVar('FAKEROOTCMD')
         self.fakerootenv = recipe_d.getVar('FAKEROOTENV')
@@ -361,6 +362,8 @@ class RecipeModified:
             recipe_d.getVar('RECIPE_SYSROOT'))
         self.recipe_sysroot_native = os.path.realpath(
             recipe_d.getVar('RECIPE_SYSROOT_NATIVE'))
+        self.staging_bindir_toolchain = os.path.realpath(
+            recipe_d.getVar('STAGING_BINDIR_TOOLCHAIN'))
         self.staging_incdir = os.path.realpath(
             recipe_d.getVar('STAGING_INCDIR'))
         self.strip_cmd = recipe_d.getVar('STRIP')
-- 
2.34.1

Re: [PATCH 6/6] devtool: code: Provide a generic C++ configuration

[adrian.freihofer]

On Thu, 2024-02-15 at 18:04 +0100, Enguerrand de Ribaucourt wrote:
> By default, the cpptools VSCode extension will use the host's headers
> and flags for linting. This results in a lot of include errors and
> misleading definitions. Even though this generic configuration
> doesn't
> include all the depenendencies, it is a proper fallback for recipe
> classes we do not accurately cover, with at least the right sysroot.
> 
> Additionally, ide-sdk automatically detects and provides a
> launch.json
> configuration for autotools recipes so we should recommend the C++
> extensions for them.
> 
> If the recipe is of another class (like Python), then the
> configuration
> will be generated but probably useless to the user. We'd need a
> mecanism
> to know if the recipe contains C/C++ but I'm not aware of any
> class-agnostic way to do it.
> ---
>  scripts/lib/devtool/ide_plugins/ide_code.py | 25 ++++++++++++-------
> --
>  scripts/lib/devtool/ide_sdk.py              |  3 +++
>  2 files changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/scripts/lib/devtool/ide_plugins/ide_code.py
> b/scripts/lib/devtool/ide_plugins/ide_code.py
> index 7b683c74086..51cf2c8a736 100644
> --- a/scripts/lib/devtool/ide_plugins/ide_code.py
> +++ b/scripts/lib/devtool/ide_plugins/ide_code.py
> @@ -157,31 +157,33 @@ class IdeVSCode(IdeBase):
>          IdeBase.update_json_file(
>              self.dot_code_dir(modified_recipe), settings_file,
> settings_dict)
>  
> +    def __vscode_extensions_generic(self, modified_recipe,
> recommendations):
Here is a condition needed. This is only valid for some C/C++ recipes.
But now these extensions are also installed e.g. for Rust, Go, Python
which is wrong.

> +        recommendations += [
> +            "ms-vscode.cpptools",
> +            "ms-vscode.cpptools-extension-pack",
> +            "ms-vscode.cpptools-themes"
> +        ]
> +
>      def __vscode_extensions_cmake(self, modified_recipe,
> recommendations):
>          if modified_recipe.build_tool is not BuildTool.CMAKE:
>              return
>          recommendations += [
>              "twxs.cmake",
> -            "ms-vscode.cmake-tools",
> -            "ms-vscode.cpptools",
> -            "ms-vscode.cpptools-extension-pack",
> -            "ms-vscode.cpptools-themes"
> +            "ms-vscode.cmake-tools"
>          ]
>  
>      def __vscode_extensions_meson(self, modified_recipe,
> recommendations):
>          if modified_recipe.build_tool is not BuildTool.MESON:
>              return
>          recommendations += [
> -            'mesonbuild.mesonbuild',
> -            "ms-vscode.cpptools",
> -            "ms-vscode.cpptools-extension-pack",
> -            "ms-vscode.cpptools-themes"
> +            'mesonbuild.mesonbuild'
>          ]
>  
>      def vscode_extensions(self, modified_recipe):
>          recommendations = []
>          self.__vscode_extensions_cmake(modified_recipe,
> recommendations)
>          self.__vscode_extensions_meson(modified_recipe,
> recommendations)
> +        self.__vscode_extensions_generic(modified_recipe,
> recommendations)
>          extensions_file = 'extensions.json'
>          IdeBase.update_json_file(
>              self.dot_code_dir(modified_recipe), extensions_file,
> {"recommendations": recommendations})
> @@ -194,8 +196,11 @@ class IdeVSCode(IdeBase):
>              properties_dict["configurationProvider"] = "ms-
> vscode.cmake-tools"
>          elif modified_recipe.build_tool is BuildTool.MESON:
>              properties_dict["configurationProvider"] =
> "mesonbuild.mesonbuild"
> -        else:  # no C/C++ build
> -            return
Same issue as above: There are many recipes were a C/C++ compiler
configuration is wrong. As a next step we might add e.g.
  elif autotools
    ...
  else
    return
but we cannot add a general else statement here.

> +        else:  
> +            # Provide a generic linting configuration
> +            # We provide a C++ configuration with the proper sysroot
> +            properties_dict["compilerPath"] =
> os.path.join(modified_recipe.staging_bindir_toolchain,
> modified_recipe.cxx.split()[0])
> +            properties_dict["compilerArgs"] =
> modified_recipe.cxx.split()[1:]
>  
>          properties_dicts = {
>              "configurations": [
> diff --git a/scripts/lib/devtool/ide_sdk.py
> b/scripts/lib/devtool/ide_sdk.py
> index 1e36f2b2093..c82b150a83e 100755
> --- a/scripts/lib/devtool/ide_sdk.py
> +++ b/scripts/lib/devtool/ide_sdk.py
> @@ -345,6 +345,7 @@ class RecipeModified:
>          self.base_libdir = recipe_d.getVar('base_libdir')
>          self.bblayers = recipe_d.getVar('BBLAYERS').split()
>          self.bpn = recipe_d.getVar('BPN')
> +        self.cxx = recipe_d.getVar('CXX')
>          self.d = recipe_d.getVar('D')
>          self.fakerootcmd = recipe_d.getVar('FAKEROOTCMD')
>          self.fakerootenv = recipe_d.getVar('FAKEROOTENV')
> @@ -361,6 +362,8 @@ class RecipeModified:
>              recipe_d.getVar('RECIPE_SYSROOT'))
>          self.recipe_sysroot_native = os.path.realpath(
>              recipe_d.getVar('RECIPE_SYSROOT_NATIVE'))
> +        self.staging_bindir_toolchain = os.path.realpath(
> +            recipe_d.getVar('STAGING_BINDIR_TOOLCHAIN'))
>          self.staging_incdir = os.path.realpath(
>              recipe_d.getVar('STAGING_INCDIR'))
>          self.strip_cmd = recipe_d.getVar('STRIP')

Re: [OE-core] [PATCH 0/6] devtool: ide: Improve VSCode support

[Richard Purdie]

On Thu, 2024-02-15 at 18:04 +0100, Enguerrand de Ribaucourt wrote:
> These patches improve the VSCode support in devtool ide-sdk from
> Adrian Freihofer.
> 
> I added a generic C++ configuration for the VScode
> extension while awaiting for autotools support.
> 
> A refactoring is proposed for the meson class. Without absolute compiler
> paths, the linter inside VSCode will not be able to find the
> cross-compiler. Let me know if you have any concerns about this
> refactoring.
> 
> The other bug fixes are relatively minor and make the tool work for some edge
> cases.

I noticed none of the patches in this series have Signed-off-by lines
which needs to be fixed before we can merge them. Patchtest should be
along shortly to say that too!

I need to think about and test the meson one a bit more as absolute
paths can be a source of problems. I've not looked into the others in
detail yet.

Cheers,

Richard

RE: [OE-core] [PATCH 0/6] devtool: ide: Improve VSCode support

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 15 februari 2024 18:11
> To: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>; openembedded-core@lists.openembedded.org
> Cc: adrian.freihofer@gmail.com; Ross.Burton@arm.com; mohammed.raza@savoirfairelinux.com
> Subject: Re: [OE-core] [PATCH 0/6] devtool: ide: Improve VSCode support
> 
> On Thu, 2024-02-15 at 18:04 +0100, Enguerrand de Ribaucourt wrote:
> > These patches improve the VSCode support in devtool ide-sdk from
> > Adrian Freihofer.
> >
> > I added a generic C++ configuration for the VScode
> > extension while awaiting for autotools support.
> >
> > A refactoring is proposed for the meson class. Without absolute compiler
> > paths, the linter inside VSCode will not be able to find the
> > cross-compiler. Let me know if you have any concerns about this
> > refactoring.
> >
> > The other bug fixes are relatively minor and make the tool work for some edge
> > cases.
> 
> I noticed none of the patches in this series have Signed-off-by lines
> which needs to be fixed before we can merge them. Patchtest should be
> along shortly to say that too!

Actually, there does not seem to be any messages about this from patchtest. 
There have been other inconsistencies reported by it since, but not these...

> 
> I need to think about and test the meson one a bit more as absolute
> paths can be a source of problems. I've not looked into the others in
> detail yet.
> 
> Cheers,
> 
> Richard

//Peter