Incorrect run folder

[Shatur]

Brief Issue Summary

Running application from CMake: Run without debugging and CMake: Debug uses project project workspace folder as run directory instead of the application build directory.

Expected:

1. Execute CMake: Run without debugging
2. The executable runs in it's own directory (for example ${workspaceRoot}/build/gui/app.exe runned in ${workspaceRoot}/build/gui/)

This how it works in QtCreator.

Apparent Behavior:

It runs in the workspace folder. This is very unconvinient because project may use plugins that need to be taken from executable folder.

Platform and Versions

• Operating System: Arch Linux
• CMake Version: 3.18.1
• VSCode Version: 1.47.3
• CMake Tools Extension Version: 1.4.1

[alan-wr]

I am not sure that this makes sense, but can provide a simple patch:

> diff --git a/src/debugger.ts b/src/debugger.ts
> index 14177e6..abac17e 100644
> --- a/src/debugger.ts
> +++ b/src/debugger.ts
> @@ -60,8 +60,11 @@ async function createGDBDebugConfiguration(debuggerPath: string, target: Executa
>      type: 'cppdbg',
>      name: `Debug ${target.name}`,
>      request: 'launch',
> -    cwd: '${workspaceFolder}',
> +    cwd: '${fileDirname}',
>      args: [],
> +
> +
> +
>      MIMode: 'gdb',
>      miDebuggerPath: debuggerPath,
>      setupCommands: [

[alan-wr]

Test snippet code:

#include <stdio.h>
#include <unistd.h>
#define MAXPATH  1024
int main()
{
    char buffer[MAXPATH];
    getcwd(buffer,MAXPATH);
    printf("\n%s\n",buffer);
    return 0;
}

[Shatur]

Will this work for run without debug too?

[alan-wr]

For 'run without debug'

diff --git a/src/cmake-tools.ts b/src/cmake-tools.ts
index e86aa73..4b03699 100644
--- a/src/cmake-tools.ts
+++ b/src/cmake-tools.ts
@@ -1370,6 +1370,7 @@ export class CMakeTools implements vscode.Disposable, api.CMakeToolsAPI {
     }
     const termOptions: vscode.TerminalOptions = {
       name: 'CMake/Launch',
+      cwd: path.dirname(executable.path),
     };
     if (process.platform == 'win32') {
       // Use cmd.exe on Windows

[Shatur]

Thank you a lot! This is just what I need. Should I send a PR for it?

[bobbrow]

Yes, please test it out and send a PR. We will be happy to review it.

[Shatur]

Done!

[Shatur]

Closed by #1397.

[bobbrow]

This is available in 1.4.2

[tndev]

@bobbrow How can that behavior be changed again (For both debug and normal run) e.g. in the launch.json or workspace setting?

That change completely messed up my setup, because I have a huge amount of data located in my working directory that I don't want to copy to my build directories.

[bobbrow]

You should be able to override the working directory with the setting:

  "cmake.debugConfig": {
    "cwd": "${workspaceFolder}"
  }

[Shatur]

@tndev, in launch.json you can just set "cwd": "${workspaceFolder}",. Read more here.

[tndev]

@bobbrow thank you for the fast response, it works now in debug with the settings cmake.debugConfig, but how do I the same to overwrite the:

  const termOptions: vscode.TerminalOptions = {
      name: 'CMake/Launch',	      name: 'CMake/Launch',
      cwd: path.dirname(executable.path),
    };	    };

[bobbrow]

Unfortunately, I'll need to prepare a patch for that. In the meantime, you could go to the source folder for the extension and delete the cwd: path.dirname(executable.path) line.

It's on line 42626 of main.js in the extension's dist folder.

Then reload the window and you're good to go. Do you know where the extension installation directory is?

[tndev]

@bobbrow Yes, I know how to change that. Thanks again.

[Shatur]

@grapland0, it is bad practice to use files relative to the source folder and not expected behavior. Just use configure_file to copy data that will be used by the application / unit tests.
If for some reason you still want to use files from the source code folder, then configure your launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CMake Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
        }
    ]
}

And you can choose a target using this plugin and run the selected target by the built-in VSCode commands.

[grapland0]

I think it is more important(and urgent) that this change breaks existing setups.

Current user of this plugin will find its target failed to run mysteriously, and has to spend minutes or hours to find the root cause.

Furthermore I don't think using files relative to the current workspace is a bad practice. At *nix, when you start anything executable, the working folder is by-default your current folder, not the folder that executable installed in.

[Shatur]

I think it is more important(and urgent) that this change breaks existing setups.
Current user of this plugin will find its target failed to run mysteriously, and has to spend minutes or hours to find the root cause.

I agree. This is not good. When I suggested this, I didn't think that someone was using the path relative to the source code folder.

Furthermore I don't think using files relative to the current workspace is a bad practice. At *nix, when you start anything executable, the working folder is by-default your current folder, not the folder that executable installed in.

But here I cannot agree. In other IDE the launch path is always executable folder.

[tndev]

@Shatur95 @grapland0 it is not that uncommon in the field of research (But I agree that the default should be the build directory).

My project code and the data are versioned with GIT and LFS in one project folder (to keep everything consistent and reproducible), copying all the data to a build directory, especially if you have a distinct build directory for debugging and release to save compilation time, is really time and space consuming (roughly 500k files with a total size of 80GB). Furthermore, changes to the data that are written back by the application, should then be tracked in the VCS again, which is another problem if the data is copied to the build directory.

Another possibility would be to create a config file with CMake, and set there the working directory as a config value and read that when the application is started. But in any IDE I used it was not a problem to set the working directory for Debug and Release builds, so there was never a need for that and as of that the change came quite unexpected.

Using the launch.json shown by @Shatur95 with "program": "${command:cmake.launchTargetPath}" seems to work fine when the menu (or shortcuts f5 and ctrl+f5) are used, but somehow have no effect on the toolbar controls (at the bottom of the window).

[Shatur]

but somehow have no effect on the toolbar controls (at the bottom of the window).

Yes, unfortunately toolbar run button are from plugin and executes target not from launch.json.
I currently also use launch.json because it allows to specify launch arguments (useful for debugging).