The -B option tells CMake what folder to perform the build in, where to barf all the configured files. On the command line, this looks something like cmake -B Builds. So it’s sorta like the prep work a kitchen will do before cooking. It’s when the CMakeLists.txt is parsed, processed and CMake spits out everything the whole laundry list of things it’s going to need to build the project. So basically, it sets up our project much like the Projucer does, but with a lot more flexibility.Įxamples of how to use JUCE’s helpers can be found in their examples directory. These helpers abstract away a lot of framework’s build configuration needs and lets you write JUCE config in the `CMakesList.txt`.įor a vanilla JUCE project, for example, you won’t see a lot of add_executable or add_library calls in the CMakesList.txt, JUCE automagically configures the targets behind the scenes. JUCE provides helper functions such as juce_add_plugin. So, for example the CMake command target_link_libraries will link a library (such as a testing framework like Catch2) to your plugin target. Modern CMake loosely refers to CMake being not quite as shitty to work with any more (vs. 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. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |