CMake: JUCE_USE_CURL / JUCE_WEB_BROWSER redefinition breaks GCC -Werror on Linux

General JUCE discussion
1

The recent develop commit 3a8dbf7d (“CMake: Automatically set curl/browser/in-app-purchases preprocessor defs based on juce_add_.* arguments”) is causing build failures with GCC and -Werror.

_juce_link_optional_libraries now adds -DJUCE_USE_CURL and -DJUCE_WEB_BROWSER on Linux. If your project already defines these via target_compile_definitions, you get two -D flags for the same macro on the command line. GCC treats any command-line redefinition as a warning, even when both values are identical, and -Werror turns it into an error:

<command-line>: error: "JUCE_USE_CURL" redefined [-Werror]

The only workaround I’ve found is to guard our definitions so they’re skipped on Linux when building against develop, but that means our CMakeLists need to know about JUCE’s internal CMake behavior, and we need a different path for older JUCE versions that don’t have this function.

Would it be possible to have _juce_link_optional_libraries skip adding the definitions if they’re already set on the target?

2

I’d like to be able to repro the issue before making any changes.

What GCC version are you using to build?
What CMake version?
Are you absolutely certain that the preprocessor definitions all have identical values? Can you check this somehow?

Here, with GCC 16 and CMake 4.3.0, I can pass e.g. JUCE_WEB_BROWSER=1 twice to target_compile_definitions, and CMake seems to automatically deduplicate it (checked by building with --verbose). Additionally, the DemoRunner and Projucer CMake builds both set the JUCE_WEB_BROWSER and JUCE_USE_CURL preprocessor definitions, and both projects build without warnings for me.

3

Sorry reuk, I had the GCC bit wrong. It only warns when the values differ.

Here’s a minimal repro: GitHub - Tracktion/cmake_issue · GitHub. Our project sets JUCE_USE_CURL=1, JUCE adds -DJUCE_USE_CURL=0, and they collide under -Werror.

Could JUCE skip the define if it’s already set on the target?

4

I think a better fix would be to pass the appropriate values for NEEDS_CURL and NEEDS_WEB_BROWSER in your juce_add_* call, is there a reason you can’t do that?

5

Hmm… not sure, it’s just the way we always did it any suddenly our builds broke. I’ll give it a try and report back. I noticed in the juce cmake files you set both NEEDS_CURL and JUCE_USE_CURL and need to keep theme in sync. Is this change so you only need to set NEEDS_CURL?

6

Ok, I got it to work. No JUCE changes required, thanks.

7

No, it’s to avoid the case where the NEEDS_* options don’t match with the preprocessor defs. If there’s a mismatch, the resulting binary will either fail to link required libraries, or will unnecessarily link libraries that are never used at runtime.