# Using CMake flow to build libraries, Android apps

**URL:** <https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492>\
**Category:** General JUCE discussion\
**Created:** [July 1, 2020, 7:59pm UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492 "2020-07-01T19:59:33Z")\
**Posts on this page:** 10\
**Page:** 2

<div class="post-metadata">

**Author:** ![brothernorth](https://avatars.discourse-cdn.com/v4/letter/b/57b2e6/32.png) [@brothernorth](https://forum.juce.com/u/brothernorth)\
**Post date:** [January 27, 2022, 9:41am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/21 "2022-01-27T09:41:21Z")

</div>

Thanks a lot, I’ll give it a try!

---

<div class="post-metadata">

**Author:** ![brothernorth](https://avatars.discourse-cdn.com/v4/letter/b/57b2e6/32.png) [@brothernorth](https://forum.juce.com/u/brothernorth)\
**Post date:** [January 31, 2022, 8:10am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/22 "2022-01-31T08:10:19Z")

</div>

Your recipe above worked (so far), thanks!

A couple of minor caveats:

1. I had to `add_library()` as `STATIC` rather than `OBJECT` for my JUCE dependencies library: CMake complained about cyclic dependencies. I guess this isn’t a problem though.

2. I had to add the `juce::` namespace everywhere (not a problem, just a note for anyone else following this)

3. I wasn’t able to use the following:

```auto
     const juce::String getApplicationName() override
     {
        return juce::ProjectInfo::projectName;
     }
 
     const juce::String getApplicationVersion() override
     {
        return juce::ProjectInfo::versionString;
     }

```

in my `juce::JUCEApplication`; I assume `juce::ProjectInfo` is created along with `JuceHeader.h`. Not a show-stopper by any means; I can hard-code them for now and worst case, just define these some other way. Would be nice to re-use the JUCE way though.

---

<div class="post-metadata">

**Author:** ![kcoul](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kcoul](https://forum.juce.com/u/kcoul)\
**Post date:** [June 28, 2022, 1:21am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/23 "2022-06-28T01:21:24Z")

</div>

Following up on this thread @reuk @eyalamir as I am trying to contribute to Eyal’s CMake template, which has every project type except for the library type - as I mostly am making libraries it would be convenient to have a Github template set up with as much of the boiler plate as possible.

I tried the above recommendations, and unfortunately it seems that for me, the call

`_juce_initialise_target(${TargetName})`

is the single difference between the template building successfully or not. Without this line, there are many errors where juce\_core’s .cpp files cannot find their own .h nor other symbols referenced from other headers.

Here’s what I have so far, if anyone can recommend a better way of doing it than this, thanks in advance!

```auto
project(LibraryTemplate VERSION 0.0.1)

set (TargetName ${PROJECT_NAME})

add_library(${TargetName} OBJECT)

_juce_initialise_target(${TargetName})

target_link_libraries(${TargetName}
        PRIVATE
        juce::juce_core
        PUBLIC
        juce::juce_recommended_config_flags
        juce::juce_recommended_warning_flags)

target_compile_definitions(${TargetName}
        INTERFACE
        $<TARGET_PROPERTY:${TargetName},COMPILE_DEFINITIONS>)

target_include_directories(${TargetName}
        INTERFACE
        $<TARGET_PROPERTY:${TargetName},INCLUDE_DIRECTORIES>)

set(SOURCES
    Source/LibraryAPI.cpp
    Source/LibraryImpl.cpp)

target_sources(${TargetName} PRIVATE ${SOURCES})

add_library(${TargetName}_shared SHARED)
add_library(${TargetName}_static STATIC)

target_link_libraries(${TargetName}_shared PUBLIC ${TargetName})
target_link_libraries(${TargetName}_static PUBLIC ${TargetName})

```

---

<div class="post-metadata">

**Author:** ![kcoul](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kcoul](https://forum.juce.com/u/kcoul)\
**Post date:** [June 28, 2022, 2:14am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/24 "2022-06-28T02:14:18Z")

</div>

This might be a better reference, I was also trying to determine in what scenarios having both a static library and a consuming CLI app using juce\_core would cause problems:

> **[Comparing eyalamirmusic:master...kcoul:master ·...](https://github.com/eyalamirmusic/JUCECmakeRepoPrototype/compare/master...kcoul:JUCECmakeRepoPrototype:master)**
>
> A prototype to model a way to create an entire repo using JUCE6 and CMake. - Comparing eyalamirmusic:master...kcoul:master · eyalamirmusic/JUCECmakeRepoPrototype

Maybe it was privately linking to juce\_core in the static library that allowed things to (seemingly) work alright?

---

<div class="post-metadata">

**Author:** ![kcoul](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kcoul](https://forum.juce.com/u/kcoul)\
**Post date:** [June 28, 2022, 8:55pm UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/25 "2022-06-28T20:55:31Z")

</div>

Here is also @eyalamir 's upstream equivalent, i noted he also needed to use the private \_juce\_initialise\_target and so there is perhaps no better way to do this as of yet. (Caveat: I suspected in some projects I worked on that libraries could compile with JUCE without this call, but only if other non-library projects were part of the same larger CMake project and JUCE had the right visibility between parts of the larger project.)

> <https://github.com/eyalamirmusic/JUCECmakeRepoPrototype/commit/594004ad6da630aa50bc05668400a462a2c9d8f1>

I was also curious about the purpose of

`target_compile_definitions(DLL PRIVATE JUCE_STANDALONE_APPLICATION=1)`

as I did not need to add it to mine for things to work.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [June 29, 2022, 3:54am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/26 "2022-06-29T03:54:37Z")

</div>

> [@kcoul](#):
>
> I was also curious about the purpose of
> 
> `target_compile_definitions(DLL PRIVATE JUCE_STANDALONE_APPLICATION=1)`

When I remove it and try to build, I get the following warning:

```auto
#ifndef JUCE_STANDALONE_APPLICATION
 JUCE_COMPILER_WARNING ("Please re-save your project with the latest Projucer version to avoid this warning")
 #define JUCE_STANDALONE_APPLICATION 0
#endif

```

And I like my builds warning-free. 🙂

---

<div class="post-metadata">

**Author:** ![jimc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jimc/32/16067_2.png) [@jimc](https://forum.juce.com/u/jimc)\
**Post date:** [June 19, 2024, 2:42pm UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/27 "2024-06-19T14:42:57Z")

</div>

So to return to a two year old convo:

> [@reuk](#):
>
> I believe that this would be true for a dynamic library built with hidden symbol visibility. I think it’s _untrue_ for static libraries. Static libraries only support visibility in the plain C++ sense (internal/external linkage), and the bulk of JUCE’s functions have external linkage. Statically linking two copies of JUCE into the same binary will result in ODR violations for this reason.

On the Mac it turns out you can pre-link your static library and avoid this problem, details are here:

[Hiding Symbols in Static Libraries with Xcode or CMake | Orange Juice Liberation Front](https://orangejuiceliberationfront.com/hiding-symbols-in-static-libraries-with-xcode-or-cmake/#:~:text=Symbol%20Hiding&text=By%20default%2C%20Xcode%20just%20leaves,flag%20%2Dfvisibility%3Dhidden%20)).

In which he says:

> A hackish way I found is to simply tell CMake to build a dynamic library, then modify the settings a bit. So instead of
> 
> ```auto
> add_library(mylibrary STATIC mylibrary.c mylibraryutils.c)
> 
> ```
> 
> your CMake file says
> 
> ```auto
> add_library(mylibrary SHARED mylibrary.c mylibraryutils.c)
> 
> ```
> 
> Of course, that just gets us a dylib. But it makes CMake call `ld`. Now that `ld` has a shot at our object files, we use
> 
> ```auto
> target_link_libraries(mylibrary -r)
> 
> ```
> 
> which will sneakily insert the `-r` parameter that indicates we want to pre-link, not generate a dylib. So instead of a file of type `MH_DYLIB` we now get an `MH_OBJECT` file, a static lib just like we wanted. However, since CMake thinks we’re making a dylib, the generated file will still be named `mylibrary.dylib` even though it is static. So we need to override that suffix:
> 
> ```auto
> set_target_properties(foo PROPERTIES SUFFIX ".a")
> 
> ```

I’m off to investigate for Windows. It’d be really useful to be able to build static libraries with the JUCE CMake system easily 🙂

---

<div class="post-metadata">

**Author:** ![Nebxl0us](https://avatars.discourse-cdn.com/v4/letter/n/b9bd4f/32.png) [@Nebxl0us](https://forum.juce.com/u/Nebxl0us)\
**Post date:** [May 23, 2025, 10:38pm UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/28 "2025-05-23T22:38:05Z")

</div>

Hey, got something very similar running right now. Was just wondering if there is any way to use juce\_generate\_juce\_header on targets that were made from add\_library?

Probably not, but I figured it’d be worth asking

---

<div class="post-metadata">

**Author:** ![FeRDNYC](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ferdnyc/32/7426_2.png) [@FeRDNYC](https://forum.juce.com/u/FeRDNYC)\
**Post date:** [October 1, 2026, 4:43am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/29 "2026-10-01T04:43:42Z")

</div>

(A 17-months-later reply to your 11-months-later question… **#SPEEDY** )

If you look at [the code for juce\_generate\_juce\_header](https://github.com/juce-framework/JUCE/blob/be29c81492b6151c8ea8d14c840e1311963b3a83/extras/Build/CMake/JUCEUtils.cmake#L584-L602), it’s very simple and really relies on only two things:

1. The target has a `JUCE_GENERATED_SOURCES_DIRECTORY` property, which is used to set `${juce_header}`, the path to the `JuceHeader.h` that will be generated.
2. The target has a `JUCE_DEFS_FILE` property, which will be set as `${defs_file}`.

Both of those paths are then passed to the `juceaide` program in a custom command, the command line for which is:

```auto
juce::juceaide header ${defs_file} ${juce_header}

```

JuceAide is what generates the `JuceHeader.h` file.

The question becomes why you’d _want_ to call `juce_generate_juce_header` _at all_, never mind on a non-JUCE target. As the [JUCE CMake API docs](https://github.com/juce-framework/JUCE/blob/be29c81492b6151c8ea8d14c840e1311963b3a83/docs/CMake%20API.md#juce_generate_juce_header) say:

> In plain CMake projects which don’t require Projucer compatibility, the use of JuceHeader.h is optional. Instead, module headers can be included directly in source files that require them.

Other than for ProJucer compatibility, there’s no need for a `JuceHeader.h` anymore, and you’re better off using more granular module `#includes` where necessary.

---

<div class="post-metadata">

**Author:** ![FeRDNYC](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ferdnyc/32/7426_2.png) [@FeRDNYC](https://forum.juce.com/u/FeRDNYC)\
**Post date:** [October 1, 2026, 4:47am UTC](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492/30 "2026-10-01T04:47:27Z")

</div>

My previous post was in reply to you, I _thought_. But I notice it’s not showing up that way in the thread, so just adding this direct reply to trigger a notification.

[Previous page](https://forum.juce.com/t/using-cmake-flow-to-build-libraries-android-apps/40492.md?page=1)