CMake juce_add_module - why do we list all cpp files in module_name.cpp?

Hi all,

in _juce_module_sources, there is a recursive glob, but then the regex filter eliminates all files except for those in the top-level that start with the module name.

Thus, the module INTERFACE library created by CMake only has module_name/module_name_xxx.cpp files as its sources. After we tell CMake to link a concrete library or executable to our module, only the top-level cpp files matching that pattern are built; we’ll get linker errors for any symbols that were defined in other source files. The only way I’ve found to build the rest of the symbols is to #include "path/to/other.cpp" from within the top-level cpp file(s).

This is the first time I’ve ever had to #include a cpp file and it’s tedious, especially in larger modules. It’s also a bit annoying because anytime one cpp file changes, the entire module has to recompile. (This might be the case anyway with INTERFACE libraries). What’s the benefit to this approach?

What’s the downside to eliminating the manual listing of cpp files and simply doing a recursive glob of all cpp files in the module source tree?

Thanks in advance

I’m thinking of abandoning juce_add_module and instead just creating OBJECT libraries from my source code using more common CMake patterns. What will I miss out on?

It looks like there are some niceties for macOS and .mm files. And _juce_add_module_staticlib_paths looks useful but I’m a bit confused because I don’t see how it applies to interface libraries.

Almost everything else in there is simply a tradeoff between describing the module metadata in the top-level .h file and describing the name, dependencies, etc in the CMakeLists.txt file for that module.

Juce modules in cmake are interface libraries; with the standard juce system, a module doesn’t actually produce any objects by itself.

You could try to work around this like you describe, but know that you’ll be violating the conventions juce has created and building the juce code in a way it’s not really meant to be built. You may encounter issues with preprocessor config flag visibility, that’s the primary reason why juce modules are interface targets.