# Native, built-in CMake Support in JUCE **URL:** \ **Category:** General JUCE discussion\ **Created:** [April 14, 2020, 10:07am UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700 "2020-04-14T10:07:26Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 15, 2020, 8:42am UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/21 "2020-04-15T08:42:54Z")
updating did fix COMPANY\_COPYRIGHT, COMPANY\_WEBSITE and COPY\_PLUGIN\_AFTER\_BUILD Thanks ! ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 15, 2020, 12:06pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/22 "2020-04-15T12:06:09Z")
What about adding `killall -9 AudioComponentRegistrar` in the AudioUnit copy phase ? Otherwise you cannot test your AU straight away. Maybe doing it only in the case of the .component not existing in the folder previous to the copy. Moreover in the plist type is wrong, it uses kAudioUnitType\_Effect instead of aufx Otherwise it’s not detected in auval At least this is what should be done according to [https://github.com/WeAreROLI/JUCE/tree/juce6/examples/CMake](https://github.com/WeAreROLI/JUCE/tree/juce6/examples/CMake) so either update the doc (and mentioning we should use single quote) or it should be converted by the cmake ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 15, 2020, 1:54pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/23 "2020-04-15T13:54:08Z")
By the way, what is the rationale when using juce in utility library as well as in the main project ? Something like that ? ``` if(NOT TARGET juce::juce_audio_basics) find_package(JUCE CONFIG REQUIRED) ENDIF() target_link_libraries(myLib PRIVATE juce::juce_audio_basics) ``` Could the lib could access to JuceHeader.h as well ? if yes what is the way to add it. ${juce\_header} ? Thanks ! ---
**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:** [April 15, 2020, 2:57pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/24 "2020-04-15T14:57:39Z")
I’m not sure exactly what you’re trying to achieve, so I might not be able to give a useful answer (sorry!). If you have a target `main` which depends on `util` which depends on `juce::juce_audio_basics`, something like this might work: ```auto # always require JUCE for the util library find_package(JUCE CONFIG REQUIRED) add_library(util) # Allows util to include headers from juce_audio_basics # Note that we *don't* want to build juce_audio_basics directly into our # util library (so no PRIVATE or PUBLIC linking here), because otherwise # we might end up with duplicate symbols (ODR violations) if we link against # other targets that also happened to contain compiled juce modules. target_link_libraries(util INTERFACE juce::juce_audio_basics) juce_add_gui_app(main) # On executable targets we *should* link privately target_link_libraries(main PRIVATE util) ``` ---
**Author:** ![Willogical](https://avatars.discourse-cdn.com/v4/letter/w/a5b964/32.png) [@Willogical](https://forum.juce.com/u/Willogical)\ **Post date:** [April 15, 2020, 3:04pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/25 "2020-04-15T15:04:17Z")
How come CMake or some other standard build system wasn’t available already as opposed to creating Projucer as the default? ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 15, 2020, 3:55pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/26 "2020-04-15T15:55:32Z")
The thing is that you want the fact that util lib uses Juce to be an internal matter to the lib itself so you want those detail to be in its CMakelist.txt of util not in the main project one. So something like that ? ``` if(NOT TARGET juce::juce_audio_basics) find_package(JUCE CONFIG REQUIRED) ENDIF() target_link_libraries(myLib INTERFACE juce::juce_audio_basics) ``` ---
**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:** [April 15, 2020, 4:14pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/27 "2020-04-15T16:14:03Z")
If it’s _definitely_ an implementation detail, then you should use `PRIVATE` linking as in your original question, but be careful not to link `myLib` into a target which includes any of the same JUCE modules as `myLib`, or you’ll run into ODR issues. The check for the existence of `juce_audio_basics` seems a bit suspect. I think it should be safe to just call `find_package(JUCE...` unconditionally in every place that it’s needed, and this will convey intent better and keep the code cleaner. You can generate a juce header for `myLib` simply by calling `juce_generate_juce_header(myLib)`. ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 15, 2020, 4:30pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/28 "2020-04-15T16:30:06Z")
If I don’t do the conditional check I have ``` CMake Error at /Users/otristan/Desktop/testJuce/JuceBuild/lib/cmake/JUCE-6.0.0/JUCEConfig.cmake:57 (add_executable): add_executable cannot create imported target "juce::juceaide" because another target with the same name already exists. ``` With stuff like boost I indeed do not have this issue. ---
**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:** [April 15, 2020, 4:32pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/29 "2020-04-15T16:32:04Z")
Ah thanks, I’ll see if I can fix this on our end. ---
**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:** [April 16, 2020, 2:50pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/30 "2020-04-16T14:50:45Z")
This commit should allow multiple calls to `find_package(JUCE)`: [https://github.com/juce-framework/JUCE/commit/1dd3b6a711d0d54bfb5bd99d176cbbf1103e8254](https://github.com/juce-framework/JUCE/commit/1dd3b6a711d0d54bfb5bd99d176cbbf1103e8254) The AudioUnit plist issue is fixed by this commit: > Thanks for all your feedback so far, please let us know if you run into any other issues. ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 16, 2020, 3:01pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/31 "2020-04-16T15:01:41Z")
Cool ! please add `include_guard(GLOBAL)` at the top level CMakeLists.txt of Juce so if I include juce using `add_subdirectory(${PROJECT_SOURCE_DIR}/../JUCE ${CMAKE_CURRENT_BINARY_DIR}/JUCE)` it works as well in the case of sub library depending on Juce as well using the same method. Thanks ! ---
**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:** [April 16, 2020, 4:03pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/32 "2020-04-16T16:03:53Z")
I’m not sure adding the same directory multiple times is something we want to encourage. Could you provide an example use-case? Perhaps there’s an alternative way of structuring the project that would sidestep this requirement altogether. I did a quick search through some other popular libraries with CMake builds and couldn’t see this being done anywhere, which suggests this isn’t a common requirement. ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 16, 2020, 4:23pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/33 "2020-04-16T16:23:31Z")
Let’s say you have a utility lib that depends on Juce for some file reading. For convenience use, you don’t want to use the find\_package which requires you to install JUCE in your system but uses the add\_subdirectory(JUCE) approach that you offer in your example. You have Juce dir in your projects root folder like some sort of SDK shared across your whole projects. Now you have your main project which uses Juce for its UI and depends on this utility lib You want to use there as well the add\_subdirectory approach. This approach is quite convenient as you only need to do a git pull to be up to date. No need to build and install the CMake manually. Clearly we update JUCE more than boost for example. This is not a common requirement because most lib will only offer the find\_package approach. and voila. ---
**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:** [April 16, 2020, 4:33pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/34 "2020-04-16T16:33:17Z")
Is there a reason you can’t just depend on the `util` library pulling in JUCE? Why do you need to add it from the top level CMakeLists too? ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 16, 2020, 4:54pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/35 "2020-04-16T16:54:01Z")
Because technically if I separate my project the right way, I have no idea or shouldn’t have to care that the util library is actually using Juce to do some of its stuff. Moreover, if at some point I change the implementation of my util lib to use boost filesystem/iostream for example I don’t want to change the cmake of my main program. make sense ? ---
**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:** [April 16, 2020, 5:32pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/36 "2020-04-16T17:32:18Z")
The main thing that’s putting me off is that, if we add `include_guard` and remove it at some point in the future (because we discover some unintended consequence of the include guard), the removal will be a breaking change. However, if we leave it out, we can add it at any point without breaking peoples’ projects. Hiding the JUCE dependency sounds nice in theory, but that’s only going to work if `util` builds as a shared library with hidden symbol visibility, so that none of the contained JUCE symbols are visible to `main`. I think in practice, if `util` is a static library you need to know that it uses JUCE because otherwise you might end up (for example) building juce\_core into both `util` and `main`. On some platforms this would result in “duplicate symbol” errors at link time, but on other platforms the duplicates will get silently discarded and the linker will just choose one set of symbols to use. If you’re lucky, this will result in weird runtime crashes when types with unexpected layouts are passed to some function (imagine `util` was built with `JUCE_STRING_UTF_TYPE=8` but `main` was built with `JUCE_STRING_UTF_TYPE=32`… strings are going to end up broken in either `util` or `main` depending on which symbols the linker decides to keep). If you’re unlucky, everything will appear to work for a while, but then break when `util` changes to a different JUCE version than `main`. At the moment this kind of project organisation just feels a bit too error-prone to explicitly endorse with an `include_guard`. ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 16, 2020, 5:40pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/37 "2020-04-16T17:40:34Z")
Your call. if you only use CMake and your util lib is added through add\_subdirectory then you don’t get the duplicated symbol issue FWIW as CMake handle this nicely. ---
**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:** [April 16, 2020, 5:55pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/38 "2020-04-16T17:55:43Z")
That would be true if JUCE was a normal staticlib target, but it isn’t. JUCE modules are separately compiled into each target that publicly/privately links against them, which means that if `util` and `main` both privately link `juce_core`, `main` will end up failing to link, or with ODR violations. For example, in this CMakeLists, `main` will fail to link with duplicate symbol errors: ```auto add_subdirectory(JUCE) add_library(util OBJECT lib.cpp) target_link_libraries(util PRIVATE juce::juce_core) target_compile_definitions(util PUBLIC JUCE_STANDALONE_APPLICATION=1) add_executable(main main.cpp) target_link_libraries(main PRIVATE util juce::juce_core) ``` Results in: ```auto duplicate symbol 'juce::String::formattedRaw(char const*, ...)' in: Modules/CMakeFiles/util.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o Modules/CMakeFiles/main.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o duplicate symbol 'juce::String::createHex(unsigned long long)' in: Modules/CMakeFiles/util.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o Modules/CMakeFiles/main.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o duplicate symbol 'juce::operator<<(juce::String&, unsigned long long)' in: Modules/CMakeFiles/util.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o Modules/CMakeFiles/main.dir/__/SDKs/JUCE/modules/juce_core/juce_core.mm.o etc. etc. ``` Note that I’m using an OBJECT library rather than a STATIC library, just to force the linker to include all object files in `main`. The only difference with a STATIC library would be that the linker may discard/ignore objects which it considers to be duplicates from the static library. This would still be an ODR error, even though the linker wouldn’t warn us! ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [April 16, 2020, 6:43pm UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/39 "2020-04-16T18:43:17Z")
Fair enough. In that case, it’s best to do that in my own code ``` if (NOT TARGET juce::juce_audio_basics) add_subdirectory(${PROJECT_SOURCE_DIR}/../JUCE ${CMAKE_CURRENT_BINARY_DIR}/JUCE) endif() target_link_libraries(util PRIVATE juce::juce_audio_basics) ``` ---
**Author:** ![yairadix](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yairadix/32/1114_2.png) [@yairadix](https://forum.juce.com/u/yairadix)\ **Post date:** [April 17, 2020, 7:13am UTC](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700/40 "2020-04-17T07:13:41Z")
> [@Willogical](#): > > How come CMake or some other standard build system wasn’t available already as opposed to creating Projucer as the default? Probably for the same reason that JUCE has its own variants of `std::unique_ptr` and `std::string` - at the time there wasn’t any standard build system. The world’s changing and it’s good that JUCE adapts to it. [Previous page](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700.md?page=1) [Next page](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700.md?page=3)