I have heard that some .h files include other .h files, but are not required to do so by POSIX etc. Thus removing them may harm portability. I am not sure how this could be detected automatically
That said I don't know much about this. And even if this is a problem, it presumably would help to know which can be removed on a particular platform, and use judgement to decide which to actually remove. On Sun, Nov 8, 2009 at 3:19 AM, Steve Litt <sl...@troubleshooters.com> wrote: > The part where you remove .h includes from .cpp is dead bang easy if rather > slow. Not so with the .h includes inside other .h files. For each #include > removal from a .h file, you'd have to compile every .cpp that includes the > including .h. > > 1.5.4 has 539 .h files and 463 .cpp files. That's roughly a quarter million > combinations. Multiply that by each #include within each .h file. Ugh! Check > this out: > > sl...@mydesk:~/junk/lyx-1.5.4$ find . | grep \.h$ | xargs grep \#include | wc > 1694 3604 90852 > sl...@mydesk:~/junk/lyx-1.5.4$ > > On the positive side, short circuit logic means that on non-extraneous > includes, the error will probably appear before all .cpp files have been > compiled. > > Also, I'm pretty sure that some #includes aren't necessary for compile, but > WILL eliminate some warnings. So the test would need to fail if any output > occurs on the gcc -Wall command. > > I'm wondering if there's a less compute intensive method than the brute force > method of removing a #include from a .h, and then recompiling every .cpp file. > > SteveT > > Steve Litt > Recession Relief Package > http://www.recession-relief.US > Twitter: http://www.twitter.com/stevelitt > > > -- John C. McCabe-Dansted
