Unable to suppress certain warnings when building with clang-cl on Windows

CMake
1

I just tried to compile a rather huge CMake-based plugin project that was built with MSVC on Windows until now with clang-cl. While this generally works, I get a lot of new compiler warnings especially

 -Wunused-local-typedef
 -Wunused-private-field
 -Wmisleading-indentation

from some in-house juce modules used in that plugin. Since these are warning that we consider to be safe to ignore, I tried to suppress them the usual way like

target_compile_options(myPlugin
    PRIVATE
        -Wno-unused-local-typedef
        -Wno-unused-private-field
        -Wno-misleading-indentation)

which I successfully did some times before. But no success here - the warnings still pop up. To verify that it’s generally working I added -Wno-asdfdasf and immediately got compile warnings about an unknown warning.

I thought I had a good understanding of CMake in the meantime but this confuses me. Any idea what I’m missing here?

2

To work out what’s going on, it may be helpful to check the build output to see which TU is emitting the errors. Is that TU definitely a part of the myPlugin target, or is it part of some other library? You’re giving the extra flags PRIVATE visibility, which means that they will only be used for source files that are built into myPlugin directly.

3

I also tried it with PUBLIC visibility, that didn’t help. The real project structure is quite complex (in reality we are speaking about roughly 600 lines of CMake code, spread over various files) and ideally all those flags should be wrapped into a dedicated compiler flag target, but the essential parts that are relevant here are

add_library(plugin_dependencies INTERFACE)
target_link_libraries(plugin_dependencies
    INTERFACE 
        in_house_juce_module_1
        in_house_juce_module_2
        some_third_party_lib)

add_library(plugin_compiler_flags INTERFACE)
target_compile_options(plugin_compiler_flags 
    INTERFACE
        -Wno-unused-local-typedef
        -Wno-unused-private-field
        -Wno-misleading-indentation)

juce_add_plugin(myPlugin, ...)

target_link_libraries(myPlugin
    PRIVATE
        plugin_dependencies


       # JUCE modules
        juce::juce_audio_utils
        juce::juce_analytics
        juce::juce_audio_basics
        juce::juce_audio_formats
        juce::juce_audio_plugin_client
        juce::juce_audio_processors
        juce::juce_core
        juce::juce_data_structures
        juce::juce_dsp
        juce::juce_events
        juce::juce_graphics
        juce::juce_gui_extra
        juce::juce_opengl


    PUBLIC

        # Linker and compiler flags nicely wrapped into targets
        plugin_compiler_flags
        juce::juce_recommended_config_flags)

Now the warnings are emitted when compiling both, our in-house modules and the plugin specific sources directly.

4

That looks fine to me. It might be worth checking the compiler command line which is emitted, in case the warnings are being disabled and then re-enabled later on in the commandline.

5

Good idea, I set the output to verbose and found out that a /W4 flag was added as the very last flag to the command line, which seems to enable those warning. This seems to come from the juce::juce_recommended_warning_flags target since it adds the MSVC flags for clang-cl here

Note that this still was the case when moving the juce flag target before our custom target in the target_link_libraries call above - but I’m not sure if this even matters at all.

I’m not sure what’s right here. I generally like the idea of adding all the recommended juce flags to the project, but this is really annoying, especially the unused local typedef seems to flag some false positives.

6

Sounds like it might be worth just duplicating and modifying the recommended_warnings_flags target in that case. If you only need a subset of the warnings, it’ll be simpler to specify the desired warnings from the outset, rather than trying to force CMake to generate the flags in a particular order.