How to modify a Rack dependency and rebuild?

Development
1

From time to time in order to debug an issue, I sometimes need to modify a dependency (rtmidi in this case). I totally have no idea how cmake works (or, in this case, doesn’t). I’m building on Windows, building from a MINGW64 console.

I expect to modify the code in Rack/dep/rtmidi/rtmidi.cpp, run make in the Rack/dep/rtmidi folder, then make in the Rack folder to relink. This doesn’t work.

I also tried make dep from the Rack folder, but it doesn’t do anything.

Any clues?

(BTW looks like the problem I’m running into is an interaction between Windows and the MIDI devices I’m using causing the Windows midiInGetDevCaps to return the wrong name for a device. Issue has been reported to Windows and the device manufacturer.)

2

The problem you are facing I believe is that the make dep rule for rtmidi doesn’t depend on the rtmidi source. It is a rule from the directory download to the lib not the contents.

So to make make dep rebuild a dep, from reading that, you would need to blow away then .a which would force that rule to run

3

Remove the dependency’s “target” binary, defined in dep/Makefile. For example for rtmidi, rm dep/lib/librtmidi.a. Then re-run Rack’s dependency build with make dep. Depending on the dependency’s build system, you might need to manually clean its build system to trigger it to rebuild the modified file.

4 Likes
4

Thanks that works! – I appreciate the response!

FWIW I worked with Pete Brown, the lead for Microsoft’s MIDI group and he acknowledged that it is indeed a Windows bug I am seeing (triggered by some small issues on the MIDI device side).

5

Now, I wish Rack would fix the bug in it’s rtmidi wrapper where it holds a reference across the release of the lock that protects that referenced data (rtmidi.cpp line 189: remove the “if” to fix).

This can cause the occasional and hard-to-reproduce UAF. the symptom is either bad reinterpretation of other data as a midi message, processing a different midi message (not a big deal — just out-of-order processing) but more often a crash.

1 Like