# Module-only repo cmake problems **URL:** \ **Category:** CMake\ **Created:** [July 9, 2026, 3:59am UTC](https://forum.juce.com/t/module-only-repo-cmake-problems/69115 "2026-07-09T03:59:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![sam-eastman](https://avatars.discourse-cdn.com/v4/letter/s/e0b2c6/32.png) [@sam-eastman](https://forum.juce.com/u/sam-eastman)\ **Post date:** [July 9, 2026, 3:59am UTC](https://forum.juce.com/t/module-only-repo-cmake-problems/69115/1 "2026-07-09T03:59:58Z")
I’m trying to make a separate repo for modules to use in multiple plugins, but have build problems. I made a narrowed down repo with minimal code. I have separate directories for modules, examples (plugins just to exercise the modules), and tests. I started with the pamplejuce template, moved things around, and used some stuff from Jan Wilczek’s course and template. > **[GitHub - sameastman/modules-template](https://github.com/sameastman/modules-template/)** > > Contribute to sameastman/modules-template development by creating an account on GitHub. I’m using CLion on macOS. The Tests target (Catch2) fails to build, looking like it can’t find juce or STL includes. ```auto ====================[Build | Tests | Debug]=================================== /Applications/CLion.app/Contents/bin/cmake/mac/aarch64/bin/cmake --build /Users/sam/code/juce/other/modules-template/cmake-build-debug --target Tests -j 6 [0/2] Re-checking globbed directories... [109/716] Building CXX object tests/CMakeFiles/Tests.dir/__/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp.o FAILED: [code=1] tests/CMakeFiles/Tests.dir/__/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp.o /usr/bin/c++ -DDEBUG=1 -DJUCE_GLOBAL_MODULE_SETTINGS_INCLUDED=1 -DJUCE_MODAL_LOOPS_PERMITTED=1 -DJUCE_MODULE_AVAILABLE_juce_core=1 -DJUCE_MODULE_AVAILABLE_juce_data_structures=1 -DJUCE_MODULE_AVAILABLE_juce_events=1 -DJUCE_MODULE_AVAILABLE_juce_graphics=1 -DJUCE_MODULE_AVAILABLE_juce_gui_basics=1 -DJUCE_MODULE_AVAILABLE_juce_gui_extra=1 -DJUCE_MODULE_AVAILABLE_module_a=1 -DJUCE_USE_CURL=0 -DJUCE_VST3_CAN_REPLACE_VST2=0 -DJUCE_WEB_BROWSER=0 -DRUN_PAMPLEJUCE_TESTS=1 -D_DEBUG=1 -I/Users/sam/code/juce/other/modules-template/tests/modules -I/Users/sam/code/juce/other/modules-template/modules -I/Users/sam/code/juce/other/modules-template/dependencies/Catch2/src/catch2/.. -I/Users/sam/code/juce/other/modules-template/cmake-build-debug/_deps/catch2-build/generated-includes -I/Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules -g -std=gnu++2b -arch arm64 -mmacosx-version-min=10.14 -fcolor-diagnostics -g -O0 -Wall -Wshadow-all -Wshorten-64-to-32 -Wstrict-aliasing -Wuninitialized -Wunused-parameter -Wconversion -Wsign-compare -Wint-conversion -Wconditional-uninitialized -Wconstant-conversion -Wsign-conversion -Wbool-conversion -Wextra-semi -Wunreachable-code -Wcast-align -Wshift-sign-overflow -Wmissing-prototypes -Wnullable-to-nonnull-conversion -Wno-ignored-qualifiers -Wswitch-enum -Wpedantic -Wdeprecated -Wfloat-equal -Wmissing-field-initializers -Wzero-as-null-pointer-constant -Wunused-private-field -Woverloaded-virtual -Wreorder -Winconsistent-missing-destructor-override -MD -MT tests/CMakeFiles/Tests.dir/ __/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp.o -MF tests/CMakeFiles/Tests.dir/__ /dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp.o.d -o tests/CMakeFiles/Tests.dir/__/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp.o -c /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:47:27: error: unknown type name 'Component' 47 | void* getNativeChild (Component& component) const | ^ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:58:5: error: unknown type name 'Component' 58 | Component* getComponent (void* nativeChild) const | ^ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:69:26: error: unknown type name 'Component' 69 | void setNativeChild (Component& component, void* nativeChild) | ^ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:83:26: error: unknown type name 'Component' 83 | void clearComponent (Component& component) | ^ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:91:5: error: use of undeclared identifier 'std' 91 | std::map componentForNativeChild; | ^ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:91:21: error: use of undeclared identifier 'Component' 91 | std::map componentForNativeChild; | ^ ~~~~~~~~ /Users/sam/code/juce/other/modules-template/dependencies/JUCE/modules/juce_gui_basics/accessibility/juce_AccessibilityHandler.cpp:91:31: error: expected expression 91 | std::map componentForNativeChild; | ^ truncated ``` The ExampleAPlugin\_All target builds with just a weird message about the vst3 signature. I can run the standalone and the AU and VST3 in Reaper. They just print a message in the PluginEditor like the default pamplejuce plugin. The PluginProcessor includes \ and adds a private member, “modules::A a;”. ```auto ====================[Build | ExampleAPlugin_All | Debug]====================== /Applications/CLion.app/Contents/bin/cmake/mac/aarch64/bin/cmake --build /Users/sam/code/juce/other/modules-template/cmake-build-debug --target ExampleAPlugin_All -j 6 [0/2] Re-checking globbed directories... [65/66] Linking CXX CFBundle shared module examples/ExampleA/ExampleAPlugin_artefacts/Debug/VST3/ExampleA.vst3/Contents/MacOS/ExampleA /Users/sam/code/juce/other/modules-template/cmake-build-debug/examples/ExampleA/ExampleAPlugin_artefacts/Debug/VST3/ExampleA.vst3: code has no resources but signature indicates they must be present -- Replacing invalid signature with ad-hoc signature /Users/sam/code/juce/other/modules-template/cmake-build-debug/examples/ExampleA/ExampleAPlugin_artefacts/Debug/VST3/ExampleA.vst3: replacing existing signature removing moduleinfo.json Build finished ``` There’s some weirdness with std::flat\_set, which is new in c++23. The only thing in module\_a (module\_a/implementation/a.h) is ```auto struct A { std::flat_set fs; std::set s; }; ``` If I don’t include \ in module\_a/module\_a.h, the plugin build fails with ```auto /Users/sam/code/juce/other/modules-template/modules/module_a/implementation/a.h:6:10: error: no template named 'flat_set' in namespace 'std' 6 | std::flat_set fs; | ~~~~~ ^ ``` I don’t need to include at all for it to build, but CLion makes “set” red. Where does the compiler normally get all the STL includes? Do they come from juce header files? If I include \ in implementation/a.h instead of module\_a.h, the plugin build fails with many errors in files under the MacOSX.sdk such as the following. ```auto In file included from /Users/sam/code/juce/other/modules-template/examples/ExampleA/source/PluginEditor.cpp:1: In file included from /Users/sam/code/juce/other/modules-template/examples/ExampleA/source/PluginEditor.h:3: In file included from /Users/sam/code/juce/other/modules-template/examples/ExampleA/source/PluginProcessor.h:4: In file included from /Users/sam/code/juce/other/modules-template/modules/module_a/module_a.h:31: In file included from /Users/sam/code/juce/other/modules-template/modules/module_a/implementation/a.h:3: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/flat_set:60: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__flat_set/flat_multiset.h:31: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__flat_map/key_value_iterator.h:18: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__iterator/product_iterator.h:58:32: error: unknown class name 'false_type'; did you mean '::std::false_type'? 58 | struct __is_product_iterator : false_type {}; | ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__type_traits/integral_constant.h:32:40: note: '::std::false_type' declared here 32 | typedef integral_constant false_type; | ^ ``` Why would it make a difference including it where its used vs in the main module header? Any other feedback on setting up a repo for modules would be appreciated. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [July 9, 2026, 8:26pm UTC](https://forum.juce.com/t/module-only-repo-cmake-problems/69115/2 "2026-07-09T20:26:54Z")
> [@sam-eastman](#): > > Why would it make a difference including it where its used vs in the main module header? In module\_a.h we’ve got this: ```auto namespace modules { #include "implementation/a.h" } ``` So if “implementation/a.h” does `#include `, then what the compiler will see is: ```auto namespace modules { // content of a.h: #include } ``` This’ll wrap all the declarations in flat\_set in `namespace modules`, which will cause problems when attempting to do symbol lookup on other stdlib headers that were included earlier, outside of `namespace modules`. ---
**Author:** ![sam-eastman](https://avatars.discourse-cdn.com/v4/letter/s/e0b2c6/32.png) [@sam-eastman](https://forum.juce.com/u/sam-eastman)\ **Post date:** [July 30, 2026, 5:22pm UTC](https://forum.juce.com/t/module-only-repo-cmake-problems/69115/3 "2026-07-30T17:22:33Z")
Thanks reuk. The Tests build failure is fixed in tests/CMakeLists.txt by replacing `add_executable(Tests ${TestFiles})` with ```auto juce_add_console_app (Tests) target_sources (Tests PRIVATE ${TestFiles}) ``` This is because in JUCEDefaults.cmake from pamplejuce’s cmake-includes, it turns on the JUCE\_ENABLE\_MODULE\_SOURCE\_GROUPS option. The JUCE CMake API documentation says, “Source groups will only work when all JUCE-dependent targets are created using the juce\_add\_\* functions. The standard add\_executable and add\_library commands are likely to result in broken builds when source groups are enabled!” The problem is alternatively fixed by leaving this option off. It’s curious that the unmodified pamplejuce works. There the juce modules are linked to the SharedCode target that’s created with add\_library and that’s linked to the Tests target created with add\_executable. Neither target uses a juce\_add\_\*.