BenCello

For obscure reasons I am trying to test part of my external's code with Catch2 framework (

). I am using cmake toolchain (on macOS) and following the documentation of Catch2 made me build/link/call Catch2 rather easily.

However, I am trying to build an "autonomous" test binary (not a bundled external object) which is not executed by Max but directly in command line. And thus I have lots of troubles linking/finding/using all Cycling's frameworks. 

Because my binary is not placed at the exact same spot as Max binary, the 

 is not the same and the frameworks are not found. I tried using 

and it worked for those two, but they are themselves calling the other frameworks (

 in the right place (relatively to my test binary) but that did not work either, 

 are still not found. Maybe because they use the 

Of course, I do not want to change the paths in the frameworks themselves, just for the test binary. And actually, I do not intend the use Catch2 to test the parts of the code which has something to do with Max/MSP/Jitter APIs, only the "pure" C/C++ methods.

Has anyone already tried this? Has somebody (from Cycling?) any idea on how to get around this?

Hi there,

For obscure reasons I am trying to test part of my external's code with Catch2 framework (https://github.com/catchorg/Catch2). I...

external-code-test-with-catch2

I don't really have an answer to your question on how to link this, but I could share some insights that might be helpful. 

The ideal approach for these types of scenarios is probably to separate your code into a core library (what you describe as "pure" C/C++) and an IO wrapper layer, where only the latter includes the Max SDK. With such an approach, you could easily just link your core library to the Catch2 framework for your tests (as well as create other wrappers if you want, for example if you want a CLI wrapper or a JUCE wrapper for your library). It seems from your description that your code more or less already is structured like this so perhaps it wouldn't be that much work to do this?

If this isn't a feasible approach, you could have a look at the min-api, which already comes with its own distribution of Catch2. While you probably won't be able to use this directly (I assume that you're using the max-sdk), you could have a look at how they handle the linking there. Most min packages have a 

 to max-sdk packages (you basically include min-pretarget.cmake and min-posttarget.cmake, which are light wrappers around max-pretarget.cmake and max-posttarget.cmake), plus the additional 

 which handles all the linking to their own 

I believe that it shouldn't be too difficult to adapt the relevant includes/definitions/properties/options from this script (plus the 

Indeed, I ended up doing a bit of both options you mentioned:

I split the code into two parts, the part "agnostic" from Max and MaxAPI that I could test with Catch2 easily in a command line executable and the part wrapping this core-code into Max objects.

And I indeed had a dive into Min API CMakeLists to see how they're doing it.

The code base I wanted to test is actually mainly written in C. So it's another (time consuming) project to convert everything to modern C++ using Min API. Nevertheless, I may do it at some point.

external code test with Catch2