In my case I had more options for the context. (VST, AU, etc) I guess it depends on your projucer settings.
In projucer you can find the “C++ Library” field inside the exporter settings for debug and release. I set the field to “LLVM C++”, closed the project and reopened it. Since then the C++11 features like atomic or unique_ptr don’t get any error messages anymore.
Thanks! I’ve found that switch but setting it doesn’t seem to make an impact.
Could you load the DSP Plugin demo straight out of the box, and let me know how it looks like on your end?
In my case, using the latest Projucer that I built from the develop branch & latest AppCode, this is what I’m getting:
I don’t get those errors. Strange.
Seems like changing the modules to “local copy” removes most of the false error messages. But I’m still getting them in strange places. Perhaps I have a wrong setting somewhere in the Projucer?
Here’s what my PluginProcessor.cpp looks like now:
First of all, thank you for considering CMake support!
For us it would be really helpful if you could support the following workflow:
Use the Projucer to select and configure JUCE modules and generate a project specific, but platform independent, CMake project which bundles JUCE as a (project specific) static library. This project has an install target which installs this library (relative to CMAKE_INSTALL_PREFIX) and creates a [MY_JUCE_LIB_NAME]Config.cmake file. In the project’s CMakeLists.txt we use FindPackage and obtain compiler flags, dependencies etc. in the CMake typical way.
This workflow is used by several projects including Amazons AWS SDK: https://github.com/aws/aws-sdk-cpp
I believe this would still be a low-hanging fruit. Your generated CMakeLists.txt could even be made compatible with “in-project” build of the JUCE library, which is probably rather helpful for people that mainly aim for CLion support.
CLion support has landed on the develop branch.
Here we’re simply creating a (concatenated) CMakeLists.txt for each supported platform rather than using a custom CMake framework for JUCE. Ultimately an approach like a few people on in this thread have suggested, where you can find_package or similar to pull in JUCE code, is the direction we will go in the future. Then, once this is in place, the CLion exporter will be migrated to the new system.
This would be great. Right now as you cannot have sub project in Projucer, it’s kinda limited for bigger app.
Thanks !
Would being able to add a custom header in each platform’s section of the generated CMakeLists.txt improve this significantly?
I’m more into a full blown cmake solution like mdsp one using find_package style
Thank you for this!
It is working, but since I want to crosscompile for linux-arm on a mac I need to edit the CMakeLists.txt every time.
set(JUCE_APPLE APPLE)
if (CC_LINUX)
set (JUCE_APPLE 0)
endif (CC_LINUX)
if (UNIX AND NOT JUCE_APPLE)
Did you have a look at FRUT (previously known as JUCE.cmake)? It might be more flexible for what you want to do. Check it out at https://github.com/McMartin/FRUT.
The CLion exporter works fine (at least with Ubuntu). It would be nice to add a field in Projucer to pass some parameters to the CMake file generated. Actually, I have to edit it manually each time the project is saved in Projucer. For information, I want to see all the warnings generated by the compiler, so I need to add the following instruction:
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
Thanks.
You shouldn’t have to edit CMakeLists.txt to add compiler flags:
So just add the desired flags to the Linux Makefile exporter.
Thanks. I didn’t know that there was a link between the CLion exporter and the others.
Is this topic still active?
All I would like to see is a official way to setup juce projects using CMakeLists. Maybe something like a few macros that do all the stuff that the projucer does. For instance, collecting files, lib dependencies. Maybe spit out some compiler flags or defines that are required for juce to work. A macro that does this proxy source include thingy.
I could write this myself but I always expect that there are some “hidden” settings I would forget.
What would be nice to is to have a way to create some files to get going. The project define header, entry points for UI apps or plugins, this kind of stuff.
Would something like this be possible? Guess I’ll have to annoy some JUCE employees at ADC '18. (Oh, I’m looking forward to this!)
My motivation to use CMake mostly comes from the fact that many other projects use cmake and this makes them easy to combine. For example, using google test is a matter of one cmake-include and setting up a target for the test suit. I also would like to create a multi-project solution.
@WilliamR: Today is your lucky day, since what you described does exist: GitHub - McMartin/FRUT: Building JUCE projects using CMake made easy
I’m the author of this project, so feel free to ask me any questions or to share with me any desires, preferably by creating an issue (Issues · McMartin/FRUT · GitHub) or by PM to avoid spamming this thread.
JUCE’s implementation is somewhat different to what you want: the Projucer will create the cmakelist files for you - not the other way around. Currently, it’s also limited to CLion support.
Will CLion support be extended? Currently it’s not possible to build multiple targets (without an annoying workaround) or use custom compiler flags for different configurations.
For example, you can only use the debugger in CLion with the Debug configuration or with the -g compiler flag, which means you have to edit the CMakeLists.txt file for different build configs as the Projucer doesn’t add that flag (even if “Debug Mode” is enabled) and compiler flags are set in the exporter, not each configuration.
I would also love to see generic CMake support, rather than just another exporter in the Projucer for CLion. While this exporter is much appreciated (!) I find it a pretty silly workflow to have to work in a powerful IDE like CLion for anything that doesn’t involve creating/deleting/renaming files, adding libraries, etc., but then switch back to the Projucer for these tasks. Intellij provides amazing support for auto-refactoring when making file changes (automatically renaming class names in headers and cpp files for example). It just doesn’t make sense to separate these coding tasks between two running native apps. I would really like to develop in CLion and not have to think about the Projucer, but just use the JUCE code like a library.
EDIT: I am checking out McMartin’s FRUT project for now 
Bump for an official way to add CMake support as an alternative to Projucer
Like this post if you feel the same way
