Re: precompiled headers and includeDB*

 <200703151144.45721.lists@...>Kurt Miller writes:
> The use of precompiled headers obscures problems with
> the includeDB* files and they have become out of date.
[snip]
> 
> I could use some guidance at this point. Do the patches
> below look correct so far?
[snip]

While we're on the subject, is there a compelling reason for the
includeDB system in general?  I guess I don't really understand that
aspect of the build system very well.  It exists because of a potential
performance gain in build times through the use of precompiled headers,
correct?

As far as I know, the system uses these includeDB files and MakeDep to
somehow build a single giant include file, which gets precompiled.
Then all files end up including this precompiled header.

This seems like a lot of trouble to go through however, and I'm not
convinced of the performance gain.  In this scheme, compilation of
file.C won't have to parse its include of file.h, but it still has to
read 1 giant precompiled header file from disk.  It would seem that
reading + parsing a small number of includes wouldn't be that much
slower (or maybe even faster) then just a read of one large precompiled
header.  Unless most headers really need to get included in a
significant portion of the JDK, which seems unlikely but possible.

So, making the unreasonable assumption that I understand things
correctly, then dependencies && includes could be done in a more
traditional way.  Performance would hopefully be similar, and that
could deprecate `MakeDeps', making OpenJDK one step closer to not
requiring a bootstrap JDK (I'm not sure if thats a reasonable eventual
goal, but from posts it seems like that would be nice).

Thoughts / corrections to my logic?

-tom