Introducing JUCE.cmake (Build your JUCE projects using CMake)

A year ago, I started to work on JUCE.cmake, a collection of tools for building JUCE projects using CMake and now I think it is mature enough to be shared with the JUCE community. If you are interested, it is hosted on GitHub: https://github.com/McMartin/JUCE.cmake.

JUCE.cmake currently contains Reprojucer.cmake and Jucer2Reprojucer. Reprojucer.cmake is a CMake module, which provides functions (all starting with jucer_*) to reproduce how a JUCE project is defined in Projucer. Jucer2Reprojucer is a console application (that you build with CMake and Reprojucer.cmake), which converts your .jucer project file into a read-to-use CMakeLists.txt file. This means that you don’t have to know a lot about CMake in order to use JUCE.cmake.

:warning: “mature enough to be shared” doesn’t mean feature complete or bug free! A lot of features are missing (no iOS support, no Android support, minimal Linux support, …), but I am actively working on JUCE.cmake and you can follow the progress by looking at the Milestones: https://github.com/McMartin/JUCE.cmake/milestones. You can also comment on the GitHub issues to say that you really want a given feature to be implemented.

If you have any questions, don’t hesitate to ask! :slight_smile:

7 Likes

Thank you!!

1 Like

Nice! This means that we can also use all the CMake usual tricks in a project?

It depends on what you mean by “usual tricks”. Do you have something particular in mind?

Link with other libraries found with a .cmake file, that kind of stuff.

Yes, you can link with other libraries, for instance using find_package().

That’s great when you have to add lots of libraries in your project in a cross platform way.
kudos :wink:

1 Like

BTW, is there anything we can do to help you proving this to JUCE 5? I guess it’s in the plan as you have lots of things under way in the GitHub repository, but as this could help me save lots of time in maintaining my plugins, I’m happy to help in some way.

@Matthieu_Brucher: thank you very much for offering some help!

The best way to help me is to test my changes to JUCE.cmake on as many platforms and projects as possible. I try to test a minimum before merging my changes, but I don’t have a Mac at home for instance, and I usually only test the JUCE’s HelloWorld and JuceDemoPlugin projects.

If you want to help me (and by “you” I mean “anyone”, not just @Matthieu_Brucher), you can send me your GitHub account name by PM and I’ll notify you on the Pull Requests. Otherwise, you can comment on any Pull Request (even closed ones), and tell me if these changes are not working as expected for you, or broke something.

My GitHub account is mbrucher, feel free to add me.
I can test the mac ports, I may not be able to fix them though (I’m still trying to figure out why Apple went maniac with all the bundle stuff, it’s a pain to understand and so different from Windows), but I’ll try my best.

1 Like

Hey @McMartin,

great project, thanks! Is there a way of doing something like this with FRUT?

add_subdirectory(subproject)
target_link_libraries(JuceProject PRIVATE SubProjectStaticLibraryTarget)

So linking an existing Static Lib Target?

Thanks!
Johannes

Hi @john_henry,

Thanks a lot for trying out FRUT!

The short answer is: yes, you can do that.

The slightly longer answer:
When you call jucer_project_end() in your CMakeLists.txt file, it creates one or more targets, depending on the type of project and the project settings. You can then refer to these targets like any other CMake target.

I hope this helps.

Don’t hesitate to create GitHub issues on https://github.com/McMartin/FRUT if something doesn’t work as expected.

Hey @McMartin,

thanks so much for explaining. This seems reasonable, but after trying https://github.com/remymuller/juce-cmake I think I’ll use this. It enables me to use CMake more natively and I don’t need the Projucer at all.

But thanks for the work you put into this! It seems very well supported!

1 Like