Juce_product_unlocking should have juce_gui_basics and juce_gui_extra as dependencies

dependencies in the BEGIN_JUCE_MODULE_DECLARATION area should include juce_gui_basics and juce_gui_extra as it contains code that depends on both.

I hit this when trying to improve our JUCE/CMake integration.

1 Like

Also juce_gui_extra on Linux needs to define linuxPackages: webkit2gtk-4.0.

Or perhaps JUCE Modules need a way to define optional deps, or maybe the webbrowser component should be in its own module (juce_gui_webbrowser)?

Another: juce_blocks_basics should define minimumCppStandard: 14 as it uses lambda capture initializers in juce_Detector.cpp (line 103, 145, 176).

I’ll get the juce_blocks_basics C++ standard updated, thanks for reporting.

As for juce_product_unlocking, the other modules are optional dependecies. The module compiles fine if they are not included as the bits that used them are wrapped in JUCE_MODULE_AVAILABLE_ guards so they won’t be included. I’m also hesitant to add the webkit package requirement to juce_gui_extra as, like you said, it can be disabled so it would always pull in that package for people even if they have the web browser disabled. Optional dependencies might be a nice way to do it, but it’ll require some thought.

For WebBrowser on Linux, maybe the default should be to disable it on Linux? I think the module definitions should probably match what the default config does?

@ed95 I had to give up on my idea to modernise our JUCE CMake stuff based on these comments for a couple of reasons.

  1. Dependencies based on options would all have to be specialed up
  2. I realised that JUCE is not fully modular. juce_X built with JUCE_MODULE_AVAILABLE_juce_Y can be different to juce_X built without. I had an idea that I would try to avoid building juce_core twice (with and without WebBrowser or OpenGL etc) when building a mixture of GUI and CLI applications.