include-what-you-use

For future reference, this I what I did to run it (needs a recent cmake, 3.3+ I think):

build iwyu out of source (needs llvm dev package)
export CPLUS_INCLUDE_PATH=/work/logiciels/rh7/llvm/5.0.0/include/c++/v1/ # needed for out of source build on some platforms
symlink llvm/5.0.0/lib in parent dir
make OTB and export compile commands:

    cmake  -DCMAKE_EXPORT_COMPILE_COMMANDS=ON  .
    make

Run iwyu:

    python ../../../../dev/include-what-you-use/iwyu_tool.py -p compile_commands.json | tee include_what_you_use.txt

IIRC, last time, IWYU had a tendency to fetch internal header files instead of project public header files.

It seems it hasn't changed. For instance, I see it wants us:

to include together

#include <itkVariableLengthVector.h>                         // for operator<<
// and
#include <itkVariableLengthVector.hxx>                       // for Variable...

to include internal stuff

#include "boost/algorithm/string/detail/classification.hpp"  // for is_any_ofF

to include the wrong header files:
```
#include <stdlib.h>
```
instead of <cstdlib>

We will need to check every proposed change before applying them.

PS: the actual list of directories where header files are located is returned by:

clang++ -stdlib=libstdc++ -Wp,-v -x c++ - -fsyntax-only

Yeah it seems like they are aware of it (see last bullet here)

Does this means that OTB internal headers (like the .txx/.hxx files) should tell what the the public header files?

I would say no since it's hopeless to have a clean iwyu output anyway. We might as well not polute our source code with pragmas, right? I don't know

Also what should be our policy concerning forward declaration? The simple ones are always good but it also suggests things that look pretty extreme:

template <class T> class __attribute__((visibility("default"))) vnl_vector;

I guess the question is should we forward declare classes from third party libs?

I patched include-what-you-use to add a new option to allow us to do it module by module. Then I went through the diff for everything in Modules/Core and edited it manually to keep only what make most sense. It's in this branch.

By doing this I learned that:

It takes a lot of effort to make something useful from the raw output of include-what-you-use (like you said @lhermitte)
It does not even analyse files that don't have a corresponding .cxx. So all of our header-only classes are simply ignored (and we have a LOT of those)
Most of what it suggests are additions, not deletions (although there are a few). Since my main interest is in removing includes in order to reduce build time, I will probably not go through the same effort for all OTB modules.

I will close this issue since I don't think the effort required is worth it any more. If anyone wants to work on it feel free to re-open.

FYI you can use the full report module by module with this command:

python include-what-you-use/fix_includes.py   --only_re="Modules.IO"  < include_what_you_use.txt

which will produce a diff in Modules.IO for example. Then manually inspect the diff and edit to make it nice.

closed

mentioned in merge request !138 (merged)

It does not even analyse files that don't have a corresponding .cxx. So all of our header-only classes are simply ignored (and we have a LOT of those)

Yes. That a recurring problem with json databases generated by CMake. They start from translation units, and have no visibility over unused header files. We need to have a lot of tests that cover all files, functions, etc.

It does not even analyse files that don't have a corresponding .cxx. So all of our header-only classes are simply ignored (and we have a LOT of those)

Yes. That a recurring problem with json databases generated by CMake. They start from translation units, and have no visibility over unused header files. We need to have a lot of tests that cover all files, functions, etc.

Since my main interest is in removing includes in order to reduce build time,

Refactoring may give better results here. I've seen a few tools on this topic -- graphs generated by doxygen+dot are a poor man's solution . BTW, it reminds me of a refactoring proposal I made for ITK that wasn't accepted (there are some files that collect miscellaneous traits and that include too many things)

Past discussion on otb-developers: https://groups.google.com/forum/#!msg/otb-developers/HOyK48NL3cI/f0cWaILy01MJ;context-place=forum/otb-developers

mentioned in issue #1649 (closed)

include-what-you-use

Designs

Child items ...

Activity