Does it matter where you add this in the top-level CMakeLists.txt file?
I can’t seem to get the modules to show up in my initial Xcode test…
Does it matter where you add this in the top-level CMakeLists.txt file?
I can’t seem to get the modules to show up in my initial Xcode test…
@dave96 good question.
You can compare/test with my example repo here: https://github.com/eyalamirmusic/JUCECmakeRepoPrototype
It only shows up for me, however, when you open the “Master” XCode project generated in the build directory and not one of the individual apps/plugins in the repo.
It should be before the call to add_subdirectory(JUCE)
. You may need to remove the build directory and regenerate it, as option
s are added to the cache and are persistent across CMake configure calls.
Yep, I think it had cached the old build generation. Deleting it and running cmake again shows them up.
Cheers @reuk!
Just updating that the Visual Studio generated solutions are still really in a bad state in terms of parsing code from JUCE modules.
It would be really great if all “shared code” targets would have all possible module sources as headers (and not separate targets) , just like it works with FRUT, Projucer based projects or the CLion exporter.
Following on from another thread, I am unable to get the modules showing up in Xcode.
I using FetchContent to grab JUCE in my CMakeLists.txt:
# Fetch JUCE
FetchContent_Declare(
JUCE
GIT_REPOSITORY https://github.com/juce-framework/JUCE.git
GIT_TAG 6.0.4
)
FetchContent_MakeAvailable(JUCE)
JUCE typically gets downloaded to ${CMAKE_BINARY_DIR}/_deps/juce-src
Could this be affecting the ability for Xcode to see the modules? Where should they be appearing?
Honestly that lack of proper module source code browsing is currently my only problem with the (great!) JUCE-cmake support, as it makes some popular IDEs like XCode and Visual Studio very uncomfortable to work with. It’s especially hard since I have a lot of custom modules.
As for myself, I mostly work with Jetbrains IDEs (AppCode/Clion) that know how to browse the directory structure correctly, but it’s not an ideal situation.
Going back to JUCE as a Git submodule solved the problem in my case
Looks like CMake: Add support for configuring modules only · juce-framework/JUCE@cc7e4d1 · GitHub broke the feature (in Xcode at least)
Before that commit, all module sources were browseable - now only the main module .mm
files are.
Bumping so this issue won’t get lost in the mix…
Should be fixed here:
It seems to add all the files in the module folder, is there any way to ignore .DS_Store and other similar things that shouldn’t appear in the project?