Replicating all of the Projucer’s functionality is a massive undertaking, and we wanted to share our work with you now to check that we’re heading in the right direction. ), and to introduce a dependency between the module and its binary data using target_link_libraries(my_module INTERFACE module_data). Using this new CMake support, it should be possible to add a binary data target with juce_add_binary_data(module_data SOURCES foo.txt bar.wav. One request from the community was to make it easier to package binary assets alongside code in a custom module. We’ve also added a helper to generate a static library containing binary assets, juce_add_binary_data. Finally, it should go without saying that all intermediate build files have been moved to the CMake build tree, so there’s no more need for the JuceLibrar圜ode folder in the source tree.ĬMake support is not limited to juce modules you can also build your personal modules with CMake by registering them with juce_add_modules. For this reason, we’ve made the JuceHeader ‘opt-in’, and it can be enabled using juce_generate_juce_header(). Similarly, the role of the JuceHeader.h is to include the AppConfig.h before all of a target’s module headers, but this becomes less useful in the absence of the AppConfig. This build-system-level support obviates the need for a dedicated AppConfig.h, so this file is not generated when using CMake-based builds. The AppConfig.h was originally designed to hold global compile definitions for a project, but CMake allows us to specify compile definitions on a target very easily, even on a per-configuration basis. If your system package manager doesn’t include a sufficiently recent CMake, you should be able to get the most recent version from the official downloads page.Īdding a whole new build system to JUCE gave us a chance to reevaluate the structure of a JUCE project in particular, the role of the AppConfig.h and JuceHeader.h. At the moment we require version 3.12 for apps, and 3.15 for plugins. One side-effect of trying to make our CMake support idiomatic is that we require some very recent CMake features in order to seamlessly handle the complexities of a JUCE project. In order to support a completely Projucerless workflow, we’ve also added some CMake-based project templates to the repo at examples/CMake that you can copy, modify, and build immediately. All of the example projects in the JUCE repo have been given new CMakeLists that you can browse to see how the support looks in practice. Modules, executables, plugins, and binary data are just normal CMake targets, and including JUCE in a project is as simple as find_package(juce CONFIG REQUIRED) or add_subdirectory(JUCE). The predominant design goal of JUCE’s CMake support is to allow users to write build configs that looks like ‘normal’ CMake. Please don’t submit packages on our behalf!) (Coming soon we’ll author packages once we’re happy that the CMake API is stable after a bit of real-world usage. allowing distribution of JUCE through CMake-based package managers, like Vcpkg and Hunter, making it faster to get started on new projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |