Mcu Support?

[Psy-Kai]

Aloha :)

The extension need a way to play nicely with something like https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug. Currently the Qbs extensions assumes that all binaries are native. Even working around this by using the plaint "run/debug" feature of vscode is not really possible since Qbs puts its build artifacts in directories with hashes (?) in the name. So setting a fixed progam path in launch.json is not possible.

I think the easy way to fix this would be to make it possible to configure the qbs.installRoot. For this to work with multiple build configurations vscodes predefines variables should be usable in qbs-configurations.json.

A better way would be to have a vscode variable containing the path to the binary. So someone could just use this variable for the program key in launch.json. I don't know if that is possible, as I don't know that much about vs codes extension api. Maybe with https://code.visualstudio.com/docs/editor/variables-reference#_command-variables? Like the (legacy) node extension does in https://github.com/microsoft/vscode-node-debug/blob/d19af1bcdffead99709ad404318a15ca879e4a75/src/node/extension/processPicker.ts#L101.

The hardest way to fix this issue would be to extend the Qbs run command (with finding debugger informations and stuff). But I think this would be too hard to implement and maintain.

[denis-shienkov]

Hi ;)

I have one question: what's a problem to set the executable path directly?

e.g.:
"executable": "path/to/bla/firmware.elf",
?

Why we need in qbs.buildDirectory and the qbs.selectedProductDirectory?

[denis-shienkov]

Also, what do you think, maybe it is better to implement these addition properties as substitutions?

By analogy with the ${sourceDirectory} and etc: https://github.com/denis-shienkov/vscode-qbs/blob/master/docs/qbs-settings.md ?

[Psy-Kai]

I have one question: what's a problem to set the executable path directly?

Think about what Qbs names its products build directories. It always includes some hash values (<product-name>.<hash>). So setting executable directly is nearly impossible. Even if you would configure the extensions build directory to just ${sourceDirectory}/build instead of ${sourceDirectory}/build/${profileName}_${configurationName} Qbs will create a subdirectory with the configuration name. So switching from debug to release will lead to a different path. Thats why we need a way to query the current build directory in the launch.json.

Also, what do you think, maybe it is better to implement these addition properties as substitutions?

You mean having a way to change Qbs settings to solve this issue? I think command variables is a better way. Before I came to the solution with the command variables I thought configuring the install root would be a viable idea. But this has different problems:

1. if the install root would be set via settings.json you would have a single install root for all profiles and configurations
2. if the install root would be set via qbs-configurations.json you need substitutions in that file too. Also the user has to manage the install root paths itself to not run in the same problem as described above in 1.

[Psy-Kai]

A more interesting question is: currently only target bin filepath and build directory can be queried. What about LD_LIBRARY_PATH? Or other environment variables? With the current implementation using launch.json to run a native application with links against dynamic libraries is not possible. And since vscode command variables only return strings querying arbitrary environment variables is not possible. But this is a flaw we cannot address because of the "comand variables only return strings" restriction.

Should I address this issue in the documentation?

[denis-shienkov]

Think about what Qbs names its products build directories. It always includes some hash values (.).

Ahhhh.. Seems I understand the issue.. Seems that the other extensions (like cortex-debug) use the `executable' property for own purposes (yes?) and in our case this property is empty (or it is hard to specify it due to a hash-like paths).. ;)

You mean having a way to change Qbs settings to solve this issue?

No, I thought to use just a new buildDirectory property as substitution, like:

"executable": "${buildDirectory}/install-root/usr/local/bin/firmware.elf",

not as a command..

But, seems, this will not work, because the other extension does not known about the value of that substitution.. yes?
And we can solve it to implement this property as a command command:qbs.getBuildDirectory which be called by the other extension.. yes?

[denis-shienkov]

A more interesting question is: currently only target bin filepath and build directory can be queried. What about LD_LIBRARY_PATH?

But we can specify the environment in the launch.json file in env property... I don't understand abit a problem.. Couls you please explain it a bit more (e.g. on a real example, e.g. how to reproduce this)?

UPD: Can we take something from the CMake extension (by analogy)? https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md

[Psy-Kai]

But, seems, this will not work, because the other extension does not known about the value of that substitution.. yes?

True. This (qbs settings) substitution is only done in this extension. No other extension nor the tasks.json/launch.json know about that substitution.

And we can solve it to implement this property as a command command:qbs.getBuildDirectory which be called by the other extension.. yes?

Exactly. But I doubt that any other extension will call qbs commands. Instead other extension will use the launch.json and its values (as the qbs extension does to detect debugger configurations). The cortex debug extension will use the executable value of a launch.json config to detect the compiled .hex/.elf file.

But we can specify the environment in the launch.json file in env property... I don't understand abit a problem.. Couls you please explain it a bit more (e.g. on a real example, e.g. how to reproduce this)?

The problem is that we don't know which env variables will be available. We could create a qbs.getLibraryPaths command which contains the values for LD_LIBRARY_PATH. But what if the run environment should contain the variable FONTCONFIG_PATH (like a Qt application might need)? In that case we don't have a command to query this environment variable. We only could provider commands to query standard environment variables (like LD_LIBRARY_PATH) but we cannot provide commands for every singe env variable anyone could ever need.

Best we could do is a env variable selector command. Imagine the following env configuration in launch.json:

"environment": [
  { "name": "FONTCONFIG_PATH", "value": "${command:qbs.selectEnvironmentVariable}" },
  { "name": "ANOTHER_VAR", "value": "${command:qbs.selectEnvironmentVariable}" },
  { "name": "HELLO_WORLD", "value": "${command:qbs.selectEnvironmentVariable}" }
]

The qbs.selectEnvironmentVariable could open a selector where the user could enter the name of the variable he wants to use. But here we would rely on the behavior of vscode. If it executes the commands in a non deterministic order we cannot do anything here.

UPD: Can we take something from the CMake extension (by analogy)? https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md

Yes but beware: I talk only about the command variables which only takes place in tasks.json and launch.json. No variable substitution of qbs settings value (like cmakes settings variable substitution).

As you see CMake currently has no solution to the library paths problem. The cmake extension only provides paths and the names of the target, build type, build kit ect. But with cmake someone could already add something like "executable": "${command:cmake.getLaunchTargetDirectory}/app.hex" to run a mcu firmware via the cortex debug extension.

I could try to mirror this cmake commands and its behavior.

[denis-shienkov]

Hmm.. ok, seems, I understand.. Let's then keep the EVN problem in the mind (maybe it can be resolved by Qbs itself, maybe we can set the desired env variables from Qbs like setupBuild/RunEnvironment as in https://doc.qt.io/qbs/qml-qbslanguageitems-module.html .. maybe)...

Ok, I will merge then your request, many thanks!