Visual Studio & can't find rack.hpp

Development
1

Newbie dev question. First, a short saga…

Just installed a development environment on my Windows PC. It was a struggle getting things to make because of a “cygheap base mismatch” which according to the message is “a result of incompatible versions of cygwin1.dll…” and to “delete all but the most recent version.” This turned out to be a wild-goose chase until I came across

which explained that “while the error message is mentioning cygwin1.dll, it is misleading as the Git for Windows is using MSYS and the file was renamed msys-2.0.dll. Unfortunately, the MSYS team forgot to change the error messages when they imported and modified the Cygwin source”. Yep, there seemed to be a conflict between msys-2.0.dll found in msys64\usr\bin and the one in \program files\git\usr\bin. Eventually got it resolved by have the git directory (an older version) first in the path.

So finally make install works and I can see the test module in Rack - YAY!

I’ve been trying out Visual Studio Code. But when I try to do the build while in the editor, I get fatal error: rack.hpp: No such file or directory

My c_cpp_properties.json has

        "includePath": [
            "${workspaceFolder}/**",
            "C:/msys64/home/zw/Rack-SDK/include/**",
            "C:/msys64/home/zw/Rack-SDK/dep/include/**"

(with rack.hpp being in that first msys64 include)

Heck, I can even dump all of the sdk include files into my project folder and I still get the error. For now, I am using the VS Code editor but keep a bash shell open to compile. But why can’t Visual Studio find rack.hpp??

2

First, congrats on the excellent cygwin debugging and the test module build! It’s a big day! :slight_smile:

You may want to look at the thread below, especially from the linked post down (on Linux initially, but it speaks to some of the same issues). I’ve been thinking of trying VSCode for Rack on Windows and am about to start prototyping a V2 module, so if that doesn’t work I’ll give it a shot myself, and if it does work please post the fix so that I don’t have to figure it out myself

Edit: this article, linked from that thread, looks super-comprehensive, and may be useful beyond just the rack.hpp issue.

1 Like
3

I think most people just compile from the command line. That’s what I do - I edit in VSC, and I compile and build from the command line.

If you really want to build inside VSC, go for it.

1 Like
4

Thanks, I came across that thread but somehow missed the medium.com article. Going to check it out and see if I can get VSCode to do the build.

2 Likes
5

I’ve been coding, building, and debugging in VS Code on Windows as long as I’ve been coding for Rack, and I got started with that guide. I do recommend understanding how to build via the MinGW terminal first, but I think VS Code is great. For me its been huge in helping me dive into the Rack source code quickly (via intellisense tooltips or right-clicking the name of any class that comes from the rack namespace). I also keep copies of the Fundamental and Audible Instruments plugin sources in my workspace so that I can search them (along with the Core modules) for quick API usage examples. The debugging works well, as long as you don’t try to set a breakpoint on the UI thread; I’ve never gotten that to work.

I think I remember that at some point I had a need to tweak something in a VS Code config file, IIRC related to absolute vs relative paths, but I can’t remember what it was exactly. FWIW here are my current configuration files:

c_cpp_properties.json (695 Bytes)
launch.json (1.6 KB)
tasks.json (1.5 KB)

Something to be aware of regarding the method in that guide and my files here, is that the building is done via reference to the Rack SDK (or a Rack source dir) while the debugging is done by attaching gdb to a full (user) installation of Rack (i.e C:/Program Files/VCV/…). This means that you need to be sure to keep both the SDK and Rack installation up-to-date separately, and your debugging environment will be the same as your everyday Rack environment with the same plugin directory (which may or may not be what is desired).

The configuration could be tweaked to instead both build and debug via a copy of Rack built from source, which would simplify maintenance and provide for separation between development & release Rack environments.

2 Likes
6

yeah, I always do dev work against rack, never the sdk. Admittedly that’s mostly because I’ve been doing it since before there was an sdk, but as you point out it does make things easier, too, in terms of versionitis.

2 Likes
7

Something else that might be useful to add to launch.json for Rack development: a set of “Launch Debug DAW” configurations, one for each DAW desired, following methods mentioned over here by @Richie. I’ll share if I get that working (I’m currently testing in Cubase), unless somebody else beats me to it.

1 Like
8

Thanks, appreciate the info and tips.

1 Like
9

Here is a version that can launch Rack in dev mode (-d launch option). To make it work, this version expects the workspace (plugin source directory) to be within a Rack source directory, i.e. RACK_DIR=../.., but it still actually launches a user-space Rack Pro installation.

I’m doing it this way, for now at least, because VS Code seems to have some unidentified issue actually launching a copy compiled from source. Because dev mode is used, the userland Rack winds up using the Rack source directory as both the system directory and user directory. We also get terminal (stderr) logging and a disabled library menu.

There are also still the old build/launch/debug options included, for whenever you want to test within your main Rack installation.

launch.json (3.1 KB)
tasks.json (2.0 KB)