Identifying unnecessary #includes
aleixpol at kde.org
Wed Mar 31 20:38:12 UTC 2010
On Mon, Mar 29, 2010 at 10:52 PM, Bertjan Broeksema <b.broeksema at home.nl>wrote:
> 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
> 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).
> what might look unneeded at a specific run on a specific machine on a
> OS etc. might be needed in another configuration.
> Another problem: often an include is not needed in the header when a
> 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
> 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
> 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
> Not an easy task, though it would be a very interesting addition to
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
Well, we can start having some tool that says which ones are definitely not
needed (which is what the plugin i added tries to).
I don't think it's about finding all the problems but about finding
problems, in the end it's still the developer who has to know what he's
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel