How to edit the BOARDS_ROOT directory collection in nRF Connect for VS Code? / Please do not add the local boards directory to the global search path

[puz_md]

Hi,

I'm currently using NCS v2.9.0 under sysbuild and have recently been using board definitions from different directories. My recent projects possess a "boards" sub-directory in the project directory.

This means when I create a branch, the boards are also copied into the branch and nRF Connect for VS Code suddenly finds/offers multiple instances/copies of my board definitions. It could happen that I change the board definition in my branch, and use the board definition from the trunk (or some other directory) for testing!

Question 1: How can I list all collected directories for the BOARDS_ROOT? How can I remove unwanted directories to clean the list up?

Question 2: Could you please change nRF Connect for VS Code so that the boards directory in the main project is not automatically added to the global search path? Please search this boards directory only when creating a build target for the corresponding project. I hope that other developers will find this more convenient, too.

Best regards,
Michael

[Edvin]

Hello Michael,

I understand. Yes. The BOARDS_ROOT folder in the VS Code extension is very sticky. 

There are two places they are collected. If you want to manually add and remove some board root directories, you can do so in the nRF Connect for VS Code extension settings:

But there you can only remove the ones that you have added through that extension setting. But as you can see from this setting's description:

The workspace folders are automatically added to BOARD_ROOT if they contain a boards/ directory. 

So if this list is empty, it means that all the board root boards are coming from the applications that you have added through the extension. This is a bit trickier to work around if you have several applications containing a board folder that actually has the board .dts/.dtsi files, and not only the board's .overlay files. 

To see what paths that are in your build command, you can copy the build command by right clicking one of the build folders in the "Applications" section in the VS Code extension:

So if you want to remove some of the paths, unfortunately, you need to remove them from the workspace. I imagine that this is a bit cumbersome, if you are jumping between projects, which is unfortunate. 

You could start removing the board files from the application, and collect them elsewhere, and add this using the extension settings, as in the first screenshot. Ideally, you should only have one version of your board files, and use .overlay files to tweak the behavior between different applications.

Another alternative is to build outside VS Code, just using a command line. 

Best regards,

Edvin

[puz_md]

Hi Edvin,

thanks for the detailed explanation! I didn't know that all projects in the workspace were evaluated, I assumed there was a hidden config file that collected all directories where board definitions had been found once in the past.

In our case, it doesn't make sense to store the board definitions in a separate repository/location and risk a mismatch of board definition and implementation. I understand that with the current NCS implementation, this will cause problems when working with branches and tags in the same workspace.

--> Is there any safe way to set BOARD_ROOT manually in the sysbuild configuration?

It would also be nice if projects in the same workspace could be deactivated. This was a pretty convenient feature of Eclipse.

One more suggestion for the NCS developers: When there are board definitions with the same name, it would be nice if NCS could at least show some path info next to them (like it does for projects that have the same name, but reside in different directories).

Best regards,
Michael

[Edvin]

Hello Michael,

Yes, I understand that this is an inconvenience in your case, and I don't think it is an unreasonable request. Our VS Code developers (when asking them about your situation) were understanding, and seemed open to limiting the workspaces, at least as an option.

Unfortunately, I don't see any workarounds for using our VS Code Extension. It is possible to add this snippet to CMakeLists.txt in a folder called sysbuild in your application's root folder, and it will be automatically picked up, but it doesn't make VS Code not append -DBOARD_ROOT="..."

list(APPEND BOARD_ROOT ${CMAKE_CURRENT_SOURCE_DIR}/../)
find_package(Sysbuild REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(sysbuild LANGUAGES)

(this will add the folder one step up from the application's root folder to your boards root).

puz_md said:

One more suggestion for the NCS developers: When there are board definitions with the same name, it would be nice if NCS could at least show some path info next to them (like it does for projects that have the same name, but reside in different directories).

Oh, so if you manage to select the correct target, does it work? In that case, that would probably be a simple workaround. What is the typical error you see when you try to select one and build? Because I suspect that the input command from the board selection doesn't contain any paths to a specific board file, but rather just the name of the board, which west would later parse all the board root folders for.

But let me know if you are able to select the correct one, and it builds without errors, and I will consider what to forward to our developers. 

Best regards,

Edvin