<div class="gmail_quote">On Mon, Mar 29, 2010 at 10:52 PM, Bertjan Broeksema <span dir="ltr"><<a href="mailto:b.broeksema@home.nl">b.broeksema@home.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Saturday 27 March 2010 20:06:50 Casey Link wrote:<br>
> Hey KDev Devs,<br>
><br>
> Amarok is working on re-organizing our code base, such that is is<br>
> compartmentalized into libraries with few inter library dependencies.<br>
> Over the years our source files have gathered many  #includes that are<br>
> cruft. Aside from manually going through hundreds of files and testing<br>
> via trial and error, we are looking for a way to identify and remove<br>
> unnecessary #includes.<br>
><br>
> We figured KDev4 and its DU chains might be able to help us. Could<br>
> someone comment on this please?<br>
<br>
</div>A lot of the information you need for such a task is available in the DUChain.<br>
However, the problem is tricky. I.e. define when an include is not needed!<br>
<br>
One problem you at least will have is the fact that the DUChain stores only<br>
information for one build configuration (i.e. the values of the defines). So<br>
what might look unneeded at a specific run on a specific machine on a specific<br>
OS etc. might be needed in another configuration.<br>
<br>
Another problem: often an include is not needed in the header when a forward<br>
declaration is added for the type specified in the included header.<br>
Additionally, it might be needed to add copy ctors and dtor (i.e. avoid the<br>
default implementations) to make a header really unneeded.<br>
<br>
Finally, a header might be needed for its preprocessor content and not its C++<br>
content.<br>
<br>
Well, lots of stuff to think about before declaring a header unneeded, hope<br>
this helps a bit. The DUChain offers you a lot of information, but you will<br>
still need to do quite some work imo to have a tool which takes in account the<br>
above described problems.<br>
<br>
I think the most important thing is to clearly describe when you consider a<br>
header as unneeded. Then, clearly describe for those cases what information<br>
you would need to determine if the header actually is unneeded. Then start<br>
with the easiest use cases, e.g. an included headers that have types and pp<br>
info defined that is not used at all. Then move on to the more trickier cases.<br>
<br>
Not an easy task, though it would be a very interesting addition to KDevelop<br>
=:).<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Bertjan<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>Well, we can start having some tool that says which ones are definitely not needed (which is what the plugin i added tries to).<br><br>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 doing.<br>