Looking for dev workflow tips: testing, debugging, profiling, editor

I am not very familiar with C++ tooling, so I’m looking for advice on how to improve my dev setup for Rack plugins.

My current workflow on Windows:

  • Write code in VSCode
  • Build with “make install” in MSYS2, launch Rack and manually test features
  • Sometimes use Rack’s logging and read log.txt for output

My issues are:

  • VSCode C++ linting is buggy and slow, so I often have to close and reopen files to make linter errors go away
  • I would like to do automated testing ( testing that certain configurations of inputs and parameters produce certain outputs as well as testing that widgets load without crashing both on the rack and in the module selector)
  • I would like to see the logs in real-time without having to search through log.txt
  • I’m not sure how to do debugging with the Rack makefile system, and ideally I would have a debugging setup with editor integration
  • I would like a profiler setup for performance optimization

The main reason I am using VSCode is because it has very good vim keybinding support with embedded neovim, so ideally I would want an editor with comprehensive vim emulation.

Any tips on improving my setup? Are there specific threads on this forum I should read?

I recommend building Rack itself, with optimization off so that you can debug into Rack, instead of using the SDK. I run/debug with that local build rather than make install, except for final testing.

Specific VSCode setup partly depends on what OS you’re developing on, and what toolchain you want to use.

My workflow is kind of insane. I don’t recommend it. But here goes:

  • I have a unit test suite. It’s all hand-rolled. It’s basically a command line program with a lot of asserts in it. If you can run it with no asserts, you are good. It is only for the algorithm (module) part of the code, and has no dependencies on VCV at all. One major side effect is that I cannot unit test any widget code.

  • Everything lives in github, and I tend to commit several times a day when I’m doing stuff.

  • I do the unit tests in old fashioned visual studio, because I know the debugger.

  • Like most ppl, I have more test code than “real” code.

  • I do all test driven design for the stuff I can test.

  • I tend to write code in visual studio code, and build and debug it in visual studio. I don’t worry too much about its linting.

  • I use VSC and msys2 just like you do to make the plugin proper and the UI.

  • I always build and debug against my own VCV, as @pachde recommends.

I recommend building Rack itself, with optimization off so that you can debug into Rack, instead of using the SDK.

this is how i’ve been working for a long time, but i’m curious about the “optimization off” part of building Rack from source. i didn’t actually know that was an option. where would i do/check this?

In the makefile, change -O3 to -O0. There are a couple of other tweaks required to build this way, but I can’t do it from where I am at the moment (in the ferry line).

I never debug up into VCV, so no reason for me to turn off optimizations. But that’s the reason - the code in the debugger looks more familiar when optimizations are off.

Thanks for the responses, @Squinky @pachde.

I am now trying to build a rack in MSYS2, but I get this error when I try to build the dependencies.

$ make dep -j16
make -C dep
make[1]: Entering directory '/c/src/Rack/dep'
cd glew-2.1.0 && mkdir -p build
cd glew-2.1.0/build && cmake -DCMAKE_SYSTEM_NAME=Windows -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX="/c/src/Rack/dep" -DCMAKE_INSTALL_LIBDIR=lib ./cmake
CMake Error: Could not create named generator MSYS Makefiles

Generators
* Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files
                                 (deprecated).
  CodeLite - Ninja             = Generates CodeLite project files
                                 (deprecated).
  CodeLite - Unix Makefiles    = Generates CodeLite project files
                                 (deprecated).
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Kate - Ninja                 = Generates Kate project files (deprecated).
  Kate - Ninja Multi-Config    = Generates Kate project files (deprecated).
  Kate - Unix Makefiles        = Generates Kate project files (deprecated).
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files
                                 (deprecated).
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files
                                 (deprecated).

make[1]: *** [Makefile:96: lib/libglew32.a] Error 1
make[1]: Leaving directory '/c/src/Rack/dep'
make: *** [Makefile:112: dep] Error 2

Any idea what’s wrong?

two things:

Now that I think about it, the deps don’t build ATM on windows. But I don’t think you are on windows?

Did you install all the packages you need to install? From the instructions on how to build VCV?

/c/src/Rack/dep looks like windows to me.

1 Like

I am on Windows and I followed the instructions from the VCV manual

Nevermind. I downgraded gcc and got it to build.

1 Like

Ok, so now I have Rack built locally and I am able to build my plugin and run it with the locally built version of Rack.

I also set up gdb debugging inside vscode and it seems to be working, however, it pauses on every call to Svg::load(asset::system(“…”)). Anybody know why?

If you want to build Rack with an updated GCC, I have a branch that fixes it:

If you want an IDE that can handle debugging; logging in real time, and may or may not work better than Microsoft’s stuff, you may want to try Eclipse. It’s a bit obtuse, IMO, and whimsy, but, hey, you may like it!

1 Like

I ran pacman -Syu in MSYS2 to update back to the latest gcc, but when I try to build your branch I get an error when it tries to build curl 7.79.1:

nonblock.c: In function 'curlx_nonblock':
nonblock.c:83:4: error: #error "no non-blocking method was found/used/set"
   83 | #  error "no non-blocking method was found/used/set"
      |    ^~~~~

Could you let me know what the tweaks are? I tried changing -O3 to -O0, and I tried removing all the optimization flags “-O3 -funsafe-math-optimizations -fno-omit-frame-pointer”, but it refuses to build without optimizations.

When debugging my version of Rack built with gcc 13.2.0 using gdb 13.2, it seems on every call to asset::system(“…”) or asset::plugin(“…”), there is a SIGTRAP happening in the destructor of the string due to a bad address during memory deallocation.

1 received signal SIGTRAP, Trace/breakpoint trap.
1: (10827) ->*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x00007ffccd9d720f",func="ntdll!RtlRegisterSecureMemoryCacheCallback",args=[],from="C:\\WINDOWS\\SYSTEM32\\ntdll.dll",arch="i386:x86-64"},thread-id="1",stopped-threads="all"
1: (10822) ->&"warning: HEAP[Rack.exe]: \n"
1: (10822) ->&"warning: Invalid address specified to RtlFreeHeap( 0000000000970000, 0000000009B7B0A0 )\n"

Anybody know what’s going on here?

You sure it’s the right branch?

Part of the fixes is not pulling that version of curl (from my dependencies makefile:

curl-8.9.1:
	$(WGET) "https://github.com/curl/curl/releases/download/curl-8_9_1/curl-8.9.1.tar.gz"
	$(SHA256) curl-8.9.1.tar.gz 291124A007EE5111997825940B3876B3048F7D31E73E9CAA681B80FE48B2DCD5
	$(UNTAR) curl-8.9.1.tar.gz
	rm curl-8.9.1.tar.gz

)

The changes can be seen here:

In essence they entail using up to date versions of curl and openssl. (The first depends on the second).

Oh, you’re right. I messed up checking out the branch. It’s building now. Thank you.

You’re welcome :slight_smile:

It ran into another error:

...
checking OpenSSL linking with -ldl... no
checking OpenSSL linking with -ldl and -lpthread... no
checking for SSL_set_quic_use_legacy_codepoint... no
configure: OpenSSL version does not speak QUIC API
configure: OPT_OPENSSL: /c/src/BloodbatRack/Rack/dep
configure: OPENSSL_ENABLED:
configure: error: --with-openssl was given but OpenSSL could not be detected
make[1]: *** [Makefile:148: lib/libcurl.a] Error 1
make[1]: Leaving directory '/c/src/BloodbatRack/Rack/dep'
make: *** [Makefile:112: dep] Error 2