Setting up a Catch2 Test target with CMake

We’re in the process of setting up tests using Catch2 for a CMake based plugin project.

We’ve run into an issue with the JuceHeader include. Since it is associated with the main project target, it is not made available to our ‘Test’ target.

Adding juce_generate_juce_header(Test) throws a CMake error:

CMake Error at cmake-build-debug/_deps/juce-src/extras/Build/CMake/JUCEUtils.cmake:877 (message):
  Target Test does not have a generated sources directory.  Ensure it was
  created with a juce_add_* function

The current two workarounds are either, directly include the module headers needed from JUCE, or add the include directory to the Test target e.g.


Is there a way to give access to JuceHeader.h from another target?

1 Like

At the moment, there’s no way to add a JuceHeader to an arbitrary target. If possible, l’d recommend that you directly include the necessary module headers where necessary. This will have the nice side effect of keeping the number of headers visible from each TU to a minimum, which may speed up builds a bit.

If that approach isn’t viable for some reason, perhaps you could create your test executable target with juce_add_console_app. This should produce a target compatible with both Catch2 and juce_generate_juce_header.

1 Like

Even though the approach that @reuk suggested is the best one, if you’re porting a big project that already has tons of JuceHeader.h includes, the quickest way is to just create a local header file in the root of your project (Say, CommonHeader.h) and copy the contents of JuceHeader.h into it.

Of course Ideally you will replace them with only the needed module includes, but find out what they are is sometimes a lengthy process…


In this case it’s a fairly new project, which is likely to get big, so feels like the right way to go.

However I do also have a very large CMake based project which suffering from long build times, so might look into removing JuceHeader in that project if it can significantly improve build times.

Is there a reason you can’t use juce_add_console_app for your test target?

Watching this thread with interest, as I’m in the middle of the exact same task, converting a new-ish projucer created project to cmake/catch2. @adamski do you plan to run both tests and builds on github actions?

No reason, that is an option, but if importing individual module headers is recommended and can reduce compile times down the road that seems preferable.

1 Like

Yes! We are using GitLab, so would be doing the equivalent there.

1 Like

I’ve been having funky issues of changes to files not being detected when using catch2 with the console_app approach – has anyone else experienced anything like that?