[Feature] - Option for linking against system Rt{Audio,Midi}

[OPNA2608]

Checklist

• I'm requesting exactly 1 feature with this issue.
• This feature hasn't already been requested.
• This feature hasn't already been implemented in the latest development build.

---

Requested Feature

An option to skip building the in-tree versions of RtAudio and RtMidi and link against their system-supplied dynamic libraries.

This could help with avoiding compilation failures caused by our pedantic error switches and is something that Linux distros would greatly prefer.

Provoked by this compilation failure in RtMidi someone sent me, specific to their 32-bit Linux CI:

midi/RtMidi/RtMidi.cpp: In function 'void* alsaMidiHandler(void*)':
midi/RtMidi/RtMidi.cpp:1612:25: error: comparison of integer expressions of different signedness: 'unsigned int' and '__syscall_slong_t' {aka 'long int'} [-Werror=sign-compare]
 1612 |           if (x.tv_nsec < y.tv_nsec) {
      |               ~~~~~~~~~~^~~~~~~~~~~

[rerrahkr]

Thanks for your request.

In that case, I think that it is possible to add -lrtaudio -lrtmidi as the compile option in BambooTracker.pro and skip including following project files:

https://github.com/rerrahkr/BambooTracker/blob/ce9eb30e88b292cf08c65302b14d8718e26c734c/BambooTracker/BambooTracker.pro#L562-L563

Currently Rerative path is used in sources when including these libraries:

https://github.com/rerrahkr/BambooTracker/blob/ce9eb30e88b292cf08c65302b14d8718e26c734c/BambooTracker/stream/audio_stream_rtaudio.cpp#L1-L6

So we need to fix includes like #include "RtAudio.hpp", and add INCLUDEPATH += $$PWD/stream/RtAudio $$PWD/midi/RtMidi to BambooTracker.pro in the normal compilation.

[alexmyczko]

I also can't wait for it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974580

[OPNA2608]

For completeness' sake I'll look into QT_ARCH-based bitness detection to disable sign-compare on 32-bit targets, but at this point I think it'd sadly be alot easier to just remove - or at the very least reduce the amount of - warning & the -Werror flags. It's very infuriating to work around all those compilation problems and selectively disable them when the main offenders come from one of 2 sources:

• misincluded system headers (using -I instead of warning-free -isystem). FreeBSD and macOS seem to do this on a large scale with all of their headers even though Clang should support -isystem afaict?
• our in-tree RtAudio & RtMidi clones which were never designed to conform to these strict compiler settings to begin with, and deviating too far from upstream will make updating them a huge burden

I wish we could selectively disable the pedantic settings for specific subdirectories to avoid all of these problems instead, since we really only need them for our own source code. Maybe we could move them into some kind of QMake subproject with its own compilation settings? I'll look into whether that's possible.

P.S. If you need a fix for those different-signedness build problems until either this or the changed flags stuff is done, you could append CPP_WARNING_FLAGS+="-Wno-error=sign-compare" to the qmake invocation, and if that fails on further warning flag related errors just keep adding whatever it complains about. As long as it's in RtAudio/RtMidi or system headers, that's really the same thing we'd be doing as well. 😕

[OPNA2608]

I wish we could selectively disable the pedantic settings for specific subdirectories to avoid all of these problems instead, since we really only need them for our own source code. Maybe we could move them into some kind of QMake subproject with its own compilation settings? I'll look into whether that's possible.

This should be the default behaviour now. Additionally, you may specify that your system-installed build of an Rt* library should be used by passing CONFIG+=system_rt(audio or midi) to avoid this whole problem completely. An extra dependency on pkg-config was added for this & the feature checks of a fallback vendored compilation of Rt*, the readme's details on this will lag behind abit until we get to a more thorough cleanup (see #297).

@alexmyczko I hope that is enough to fix your build problems on 32-bit systems & link against Debian's Rt* libs?