It is alpha software but it seems like you may have employed some bad practices in your C++ projects and taking your frustration out on IWYU, which has pointed them out.
Even if you don't see an immediate benefit in CI times, it may still be a good idea to clean up unnecessary includes.
That's a lot of words to say your codebase sucks ;)
These are all criticisms of your own codebase, IWYU is just pointing out the issues. Some of the criticisms are probably legitimate, but hard to tell when so many are so odd.
Almost any talk about the merits and demerits of C++ programming methods brings into question, for those not committed to C++, the merits and demerits of C++ itself.
Relevant is Figma's recent experience fixing this issue, they didn't end up using IWYU but made their own tool which unfortunately doesn't appear to be open source:
I'm surprised TFA didn't see any improvement though. It makes me wonder if there's bigger opportunities with the build graph shape preventing them from getting optimal incremental rebuilds.
Include-what-you-use won't make your stuff build faster, unless you end up removing lots of headers. What it will do is make your codebase more stable by forcing people to include stuff that is referenced in the current file. Some people find it annoying when their indirectly included header changes or disappears and that breaks the build. I believe there is also the expectation that you will forward declare tons of stuff. That will speed up your build, but it's a lot of work. I wouldn't do it unless I had serious problems with build times that couldn't be solved otherwise.
I haven't used IWYU in years. It's an ok idea but I have bigger fish to fry, and including everything you reference is kinda verbose. What I do is I include anything particular to the current cpp file, and let everything else be indirect. If it someday breaks the build when I change includes upstream, I'll fix it. That takes less time than maintaining IWYU stuff IMO.
Of course if you are writing headers, you really ought to be more careful and include more stuff, if it's fast enough at compile time. It's stupid to have to include a header and then have to include a separate header with primitive types or something before you can do anything.
6 comments
[ 9.1 ms ] story [ 62.9 ms ] threadEven if you don't see an immediate benefit in CI times, it may still be a good idea to clean up unnecessary includes.
13 April 2011
Work has been continuing at a furious pace on include-what-you-use. It's definitely beta quality by now. :-) Well, early beta.
These are all criticisms of your own codebase, IWYU is just pointing out the issues. Some of the criticisms are probably legitimate, but hard to tell when so many are so odd.
https://www.figma.com/blog/speeding-up-build-times/
I'm surprised TFA didn't see any improvement though. It makes me wonder if there's bigger opportunities with the build graph shape preventing them from getting optimal incremental rebuilds.
I haven't used IWYU in years. It's an ok idea but I have bigger fish to fry, and including everything you reference is kinda verbose. What I do is I include anything particular to the current cpp file, and let everything else be indirect. If it someday breaks the build when I change includes upstream, I'll fix it. That takes less time than maintaining IWYU stuff IMO.
Of course if you are writing headers, you really ought to be more careful and include more stuff, if it's fast enough at compile time. It's stupid to have to include a header and then have to include a separate header with primitive types or something before you can do anything.