![]() Locally, you’ll probably just use your IDE to build. One can compile the executable directly with the configured tool chain by passing -build. You won’t actually need to generate anything, just open the project… It Builds Visual Studio and CLion both have built-in CMake support which keeps you off the command line. On MacOS this will build you an Xcode project such as myProject.xcodeproj cmake -B Builds -G Xcode On windows, this will create a solution file such as Projname.vcxproj cmake -B Builds -G "Visual Studio 17 2022" The idea is you generate a project file and then open it and compile from the IDE. If you pass -G, CMake outputs project files for system specific build tooling and IDEs. Tip: Some IDEs such as CLion will automatically detect and run the configure step, using the folders cmake-build-debug and cmake-build-release and so on. 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. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |