On Sun, Nov 08, 2009 at 12:55:15AM +0100, Vincent van Ravesteijn wrote: > Pavel Sanda schreef: >> Vincent van Ravesteijn wrote: >> >>>> my draft implied one compilation per one #include in our sources, no >>>> combinations. the only tweaking part was that detection in .h files >>>> - one has >>>> to distinguish whether the compilation fails because of header >>>> insuficiency in >>>> .h or in consequent .cpp which includes it. >>>> >>>> pavel >>>> >>> Yes, but if you include ten .h files, and each one includes ten >>> other .h files, then it is very difficult to find the least amount of >>> includes that are needed. And in the end, it might not even have any >>> influence on building times as one .h file is often included through >>> some detours. >>> >> >> i didn't claim we will find optimal solution. but if this script is going to >> happen i believe it will speed up the compilation. >> >> pavel > > I think you'll mostly remove includes that are redundant in some sense. > It's less likely there are huge amounts of costly includes.
A while ago there was quite some effort to remove unnecessary includes. I don't think that there was much avoidable left at that time. The next step (that was also partially taken) was to avoid stuff that was really expensive to use. There's still development/tools/numbers that gives a rough idea what the costs of individual #includes are. Andre'
