The Toolchain is your complier, debugger, and so on. Your IDE might let you setup build configurations for each target. If you have a plugin, each plugin version (AU, VST3) is actually its own target. You might have your app target and then a test target. They might have dependencies on each other. These can be configured and built discretely. Or your testing library like Google Test or Catch2.Ī Target is an executable or library that gets configured and compiled. It could be a juce module or some cool library you found on github. Ok, so let’s define a few things you’ll need to know.Ī Library is a chunk of code. The documentation often assumes you know the basics (what “configuration” means, what a “target” is, etc.) Some Jargon In my opinion, this is the reason CMake has the (deserved) reputation for being “hard”: a lot of complexity results from all the implicit coupling between these different concerns.ĬMake also builds on an long historical foundation of Makefiles, etc. You’ll just have to get used to what flags you should be passing, it’s not too tough! The CLI commands you’ll issue on the command line are also all mashed together in one tool. Instead, it’s all mashed together in one big happy festival of configuration directives. Unfortunately, these discrete jobs are not separated in CMake’s config. So, CMake seems to do a lot of different jobs. You might also see CMakeList.txt files in sub directories and oh boy then things start to get really complicated. This makes it really useful for running on the command line in CI environments.Īll of these things are configured by a CMakeLists.txt file that sits in the root directory. It also configures and builds executables. So one main thing CMake does is exports “build tool files.” What role does CMake play?ĬMake is the “glue” that lets you configure and build your JUCE project for multiple platforms.īefore the CMake integration was announced the only way to do this was via JUCE’s custom app, the Projucer. You can also out Pamplejuce, a GitHub template I made for JUCE + CMake + Catch2 + GitHub actions.
I’ll explain what I can here in hopes it’ll help future plugin devs. You don’t need to be an expert, but it’s worth knowing the basics. However it’s a very useful tool to get up to speed on.
#Cmake visual studio multi jobs full#
Plus the ecosystem is full of jargon, naming disasters, legacy cruft… I wasn’t totally clear on a few high level concepts at first. CMake took me a bit of wrestling ( especially on Xcode).
0 kommentar(er)
