Identifying unnecessary #includes

[Bertjan Broeksema]

On Saturday 27 March 2010 20:06:50 Casey Link wrote:
> Hey KDev Devs,
> 
> Amarok is working on re-organizing our code base, such that is is
> compartmentalized into libraries with few inter library dependencies.
> Over the years our source files have gathered many  #includes that are
> cruft. Aside from manually going through hundreds of files and testing
> via trial and error, we are looking for a way to identify and remove
> unnecessary #includes.
> 
> We figured KDev4 and its DU chains might be able to help us. Could
> someone comment on this please?

A lot of the information you need for such a task is available in the DUChain. 
However, the problem is tricky. I.e. define when an include is not needed!

One problem you at least will have is the fact that the DUChain stores only 
information for one build configuration (i.e. the values of the defines). So 
what might look unneeded at a specific run on a specific machine on a specific 
OS etc. might be needed in another configuration.

Another problem: often an include is not needed in the header when a forward 
declaration is added for the type specified in the included header. 
Additionally, it might be needed to add copy ctors and dtor (i.e. avoid the 
default implementations) to make a header really unneeded.

Finally, a header might be needed for its preprocessor content and not its C++ 
content.

Well, lots of stuff to think about before declaring a header unneeded, hope 
this helps a bit. The DUChain offers you a lot of information, but you will 
still need to do quite some work imo to have a tool which takes in account the 
above described problems. 

I think the most important thing is to clearly describe when you consider a 
header as unneeded. Then, clearly describe for those cases what information 
you would need to determine if the header actually is unneeded. Then start 
with the easiest use cases, e.g. an included headers that have types and pp 
info defined that is not used at all. Then move on to the more trickier cases.

Not an easy task, though it would be a very interesting addition to KDevelop 
=:).

Cheers,

Bertjan