Include-what-you-use

include-what-you-use is a nice tool making C++ more beginner friendly and have the same redundant import warnings given by modern languages like Rust. It makes build times faster and etc it’s probably great, but

it doesn’t work out of the box with JUCE as it may tell you to #include "juce_core/unit_tests/juce_UnitTest.h" when that just doesn’t work.

This can be fixed with using a .imp “mapping file” as follows:

[
    { include: ["@\"juce_core/.*\"", "private", "<juce_core/juce_core.h>", "public"] },
    { include: ["@\"juce_dsp/.*\"", "private", "<juce_dsp/juce_dsp.h>", "public"] }
]

(this mapping file example is very partial)

To try it too you’ll need to add the following in your CMakeLists.txt (works for me with the Unix Makefiles cmake build):

find_program(iwyu_path NAMES include-what-you-use iwyu OPTIONAL)
set(iwyu_options "-Xiwyu" "--mapping_file=${CMAKE_SOURCE_DIR}/juce.imp")
if(iwyu_path)
    set_property(TARGET FWDBWD PROPERTY CXX_INCLUDE_WHAT_YOU_USE "${iwyu_path};;${iwyu_options}")
endif()

(on macOS also brew install include-what-you-use)

Does anyone else here use iwyu with JUCE? @eyalamir ?

3 Likes

I don’t but like the idea of it.
CLion has a similar inspection: Inspection: Unused include directive | CLion Documentation

1 Like

Does the CLion inspection work for you out of the box with JUCE?
Do you know if they use iwyu or if they made their own competing implementation?

1 Like

I’ll be honest, I’ve never really paid attention to it

1 Like

I don’t use it. I believe CLion uses it’s own inspections for that. The CLion inspections work for me with my own modules (that have explicit includes) but not for the built in JUCE modules (that have implicit includes through the module header).

1 Like