Debug in VSCode with Rack-SDK?

We have lots of stuff now. We just need the @Vortico answer of why its unable to unzip :smile:

1 Like

This is an old post but I got debugging working in part thanks to it. So i guess I will share how i did it.

I have a “Rack-SDK” folder and inside it a “.vscode” folder with this files.

settings.json

{
  {
    "terminal.integrated.shell.windows": "c:\\msys64\\usr\\bin\\bash.exe",
    "terminal.integrated.shellArgs.windows": ["--login"],
    "terminal.integrated.env.windows": {
        "CHERE_INVOKING": "1",
        "MSYSTEM": "MINGW64"
    }
}

task.json

{
  {
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build VCV Rack plugin",
            "type": "shell",
            "command": "make install -j4",
            "options": {
                "cwd": "${workspaceFolder}/plugins/LomasModules",
                "env": {
                    "PATH": "C:\\msys64\\usr\\bin\\;C:\\msys64\\mingw64\\bin"
                }
            },
            "problemMatcher": {
                "owner": "cpp",
                "fileLocation": [
                    "absolute"
                ],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5
                }
            }
        },
        {
            "label": "Build VCV Rack plugin & lauch Rack",
            "type": "process",
            "command": "C:\\Program Files\\VCV\\Rack\\Rack.exe",
            "problemMatcher": [],
            "dependsOn": ["Build VCV Rack plugin"],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

launch.json

{
  {
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "C:\\Program Files\\VCV\\Rack\\Rack.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "Build VCV Rack plugin"
        }
    ]
}

After those files gdb started running but line breakpoints did not work. The key was what @Richie said:

ifdef ARCH_MAC
	$(STRIP) -S dist/$(SLUG)/$(TARGET)
else
	# RJH $(STRIP) -s dist/$(SLUG)/$(TARGET)
endif

After commenting that line the breakpoints are working.

If you want to use the files you will have to change the plugin relative path “${workspaceFolder}/plugins/LomasModules” to point to your plugin folder. Also you may need to change the paths to gdb, gcc, and rack. I have MSYS2 on c: and Rack on Program Files.

3 Likes

Okay then. I’m going ahead and share my debug config for MacOS. I didn’t use the SDK but checked out the complete VCVRack from github and compiled it.

Using the C/C++ Extension from Microsoft.

Rack/.vscode/c_cpp_properties.json

{
  "configurations": [
    {
      "name": "Mac",
      "includePath": ["${workspaceFolder}/**"],
      "defines": [],
      "macFrameworkPath": [
        "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks",
      ],
      "compilerPath": "/usr/bin/clang",
      "cStandard": "c11",
      "cppStandard": "c++11",
      "intelliSenseMode": "clang-x64"
    }
  ],
  "version": 4
}

Rack/.vscode/launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(lldb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "Rack",
      "args": ["-d"],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "lldb"
    }
  ]
}

I’m not using a launch task, just using the terminal for executing make make dep for Plugins but not installing them. I’m running Rack from the source folder of rack and the plugins subdirectory. Works like a charm. And you have two isolated environments, when running Rack in development mode with "args": ["-d"].

2 Likes

Yep! This worked for me as well. I’ve got my plugin debugging working after removing the $(STRIP) command. strip -s removes the debugger symbols as commented in compile.mk and confirmed here. I’ve added a makefile argument that I set from the command line to alternate between stripping and not stripping depending on if I want to debug or not.

Thanks for the confirmation @lomasmodules and the help @Richie! Now I can really dive into some fun!

FYI:

I’ve written a more detailed article on how I got my Windows environment setup for step by step debugging and building. Hope it helps!

4 Likes

Could some kind, patient individual talk me through how to get VS Code debugging working under linux please?

Ok, could someone help me just to get the damn thing to build upon hitting F5? If I can get that working perhaps I’ll be able to sort the debugging out myself.

c_ccp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**",
                "/home/ewen/Rack/**",
                "/home/ewen/Rack-SDK/dep/**",
                "/home/ewen/Rack-SDK/include/**"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64"
        }
    ],
    "version": 4
}

tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build vcv rack plugin",
            "type": "shell",
            "command": "make install",
            "options": {
                "cwd": "${workspaceRoot}",
                "env": {
                    "RACK_DIR": "/home/ewen/Rack-SDK/**"
                }
            },
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
        {
            "type": "shell",
            "label": "g++ build active file",
            "command": "/usr/bin/g++",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/${fileBasenameNoExtension}"
            ],
            "options": {
                "cwd": "/usr/bin"
            }
        }
    ]
}

Output:

> Executing task in folder RacketScience: /usr/bin/g++ -g /home/ewen/Rack/plugins/RacketScience/src/RSPhaseOne.cpp -o /home/ewen/Rack/plugins/RacketScience/src/RSPhaseOne <

In file included from /home/ewen/Rack/plugins/RacketScience/src/RSPhaseOne.cpp:3:0:
/home/ewen/Rack/plugins/RacketScience/src/plugin.hpp:2:10: fatal error: rack.hpp: No such file or directory
 #include <rack.hpp>
          ^~~~~~~~~~
compilation terminated.
The terminal process terminated with exit code: 1

Running make install in the terminal works fine.

Clueless, frustrated & grateful for any assistance.

In task.json try to put your plugin folder

“cwd”: “${workspaceRoot}/plugins/pluginname”

I use ctrl+B to run it, not F5.

Thanks, no change.

I use emacs, but from looking at the json, why do you have a ** after the Rack-SDK directory?

env": {
                    "RACK_DIR": "/home/ewen/Rack-SDK/**"
                }

That looks wrong. I thought ** expanded directories.

If RACK_DIR is set wrong you won’t find rack.hpp

Thanks, amended, no change.

Oh sorry looking more closely: It looks like you are running the second (g++) command not the first (make install). The one time I used VSCODe I did remember having to pick the right task. Are you sure that second blob of json isn’t running? That has none of the env set up to build at all.

The command line shown (g++ foo.cpp) won’t work; you want to just issue a make to get all the makefile stuff included.

Thanks, that appears to be the case, no idea how to specify which one runs.

Ctrl shift b I think? Or a menu to run a build task? That’s from a quick google and remembering the one day I tried to switch from emacs

1 Like

And there was much rejoicing!!! Thank you :slight_smile:

Now to try & get the debugger debuggering.

1 Like

All sorted, debugger running, breakpoints working having removed STRIP as per above, happy bunny.

Yay! Every few months I think of finally retiring my emacs habit (Which I just realized I have now had for a long time…) and moving to VSCode. Maybe 2020 is the year to do that. Maybe.

1 Like

Love it, it cured my sublime habit overnight.

This helped very much; I went from never having used VSCode to successfully debugging with it. Thank you!

This thread has helped me get on my way to building my own modules using Visual Studio Code (and later full-blown Visual Studio), thanks so much to everyone involved!

In that spirit, I would like to share the following, and maybe add another useful tip for the next person to come along… It really bugged me to have to make changes to the Rack SDK files, as I didn’t want to have to keep changing them when I wanted to build a debug version, and I would prefer to leave my SDK folder untouched and keep my changes within the scope of my project. So I added the following targets to my Makefile, which allows me to switch between a debug and release build:

# When building for debugging, stop the debug symbols from being stripped, and set the optimization level to none
debug: STRIP = : DEBUG MODE, THIS LINE IS COMMENTED OUT:  strip
debug: EXTRA_FLAGS = -O0
debug: clean dist
	cp dist/"$(SLUG)"-"$(VERSION)"-$(ARCH).zip $(RACK_USER_DIR)/plugins-v1/

release: clean install

It pre-defines the strip variable to be a comment, so that the stripping does not take place, then adds a flag for no optimizations, which will be added after the normal flags, overriding them. Hope someone finds it useful!

1 Like

I’m trying to debug in VSCode on a mac, and I’ve successfully got compilation working, and the debugger is running, but as soon as I get to APP->window->run(); in main, I can’t seem to step into the code. Is that normal? Am I not building with the right debug flags possibly?

I have:

  • removed the -O3 option from compile.mk
  • commented out the strip call from plugin.mk
  • switched BND_INLINE from inline to static in blendish.c

cleaned and recompiled but somehow everything inside of APP->window->run(); seems invisible to the debugger.

I’ll give it another crack tomorrow, maybe I need to start from a fresh clone, but thought I’d ask just in case anybody has a suggestion.

It’s my first time testing out the debugger on VSCode, I’m quite impressed with how well it integrates when it works.