I know it’s unauthorized third party, but maybe it would be good to talk and see how to fix that. Porting an application from juce-cmake must be done in one go, as we have namespace clashes between that module and yours.Ok, I could spend some more time looking at this. I later link bspe privately against a target created with juce_add_plugin, which builds all of the necessary JUCE sources and bspe sources (once) into the final plugin. When structuring code this way, each of the bspe_* source files is able to include JUCE module headers as expected. Target_link_libraries(bspe INTERFACE arbe juce::juce_audio_utils Boost::boost) In a personal test project, my CMakeLists for one custom library looks like this: add_library(bspe INTERFACE)īspe_pluginprocessor.cpp bspe_pluginprocessor.h At the moment, I’d recommend structuring user code as JUCE modules, or as CMake INTERFACE libraries. The JUCE 6 CMake support only allows generating JuceHeaders for targets created with a juce_add_* functions - this mirrors the behaviour of the Projucer, but may not be flexible enough to port a juce-cmake project without changes. I am thinking about potential solutions to this problem, but it’s surprisingly tricky to get right. The short answer is that there’s not a good way to build JUCE as a staticlib using CMake at the moment. I feel I am completely on the wrong track here? Normally, I’d just say add_target_include_directories(), but that is as we all know forbidden because then you are excluding the AppConfig.h and the Juce headers bark. in INTERFACE mode, it doesn’t find the headers (probably because I do add JUCE as a subdirectory from the top-level CMake), and in PRIVATE mode it does find them but also builds and links the juce.cpp files, which I do not want as it will lead to subsequent duplicate object errors as outlined above. The commands above with the traditional add_library() … add_link_libraries() for whatever reasons don’t work for me. I think we are lacking an example for a “user custom module” with Cmake, I only found plugin, console, and gui. Now, what would be the proper new Juce 6 way? I tried porting that simple app tonight, but didn’t get very far. I understood from above that this is a dangerous thing to do as the headers are not independent of each other, but ok, so far that worked. What I do - and I feel this is not recommended practice - is to split up my code into static libraries that rely only on JuceHeaders, and compile one executable as a proper Juce application, linking in my libraries. Sorry to jump into the middle of this thread, but I think I read it now 3 times and I am still at a loss on how to add libraries/modules of my own.īackground - I have been using Remymuller’s juce-cmake for now, and a simple example of my usage in action could be seen at. If you’re not sure how to set up a CMake project after reading this document and looking at the example projects, let us know here on the forum and we’ll try to improve the documentation. This being the case, I think that time spent adding a new CMake exporter to the Projucer would better be spent improving/extending the CMake API documentation (currently located in examples/CMake/readme.md). This in turn would require users to be familiar with JUCE’s CMake API. Thereafter, users would still have to edit the CMakeLists directly if they wanted to make changes. Given that users must be free to modify the generated CMakeLists as they see fit, the Projucer could only be used to generate an initial project. The CMakeLists must remain the ‘single source of truth’ if we want to allow this kind of usage. We expect that most users of the CMake support will use it for functionality that simply doesn’t (and can’t) exist in the Projucer: stuff like linking against other CMake targets or writing helper functions to configure multiple targets with minimal boilerplate. The new standalone CMake support behaves in exactly the same way: when using CMake, the project CMakeLists are now the ‘single source of truth’ for project configuration, and CMake generates Xcode/VS projects which may get overwritten when reconfiguring the project. Users know that when making changes inside the Projucer, any changes to the generated project files (Xcode projects, VS projects, makefiles etc.) will be overwritten. Any changes to the build settings should happen inside the Projucer, so that the settings are propagated to all the exporters as appropriate. Currently, the Projucer is designed to act as the ‘single source of truth’ for JUCE project setup. At the moment I’m not sure adding a new CMake exporter to the Projucer is a good idea.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |