# 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:** 1\ **Showing post:** 36
**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`. --- _[View the full topic](https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700)._