This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compile server design document
Joseph S. Myers wrote:
The dependency system seems very complicated (necessarily) and potentially
fragile.
It could be. The compile server is an option, and should not
be the default, certainly not anytime soon.
I argue that it may be acceptable for the compile server to
get confused in certain pathological cases, but we want to
minimize the chance of that happening. Ideally, we want to
compile exactly the same code and emit exactly the same
errors messages with and without the server, but approaching
that goal is an incremental process that will require experience
plus smart thinking.
Note that any place where an identifier is lexed as not
currently declared as a typedef, this must be treated as having a negative
dependency,
I think this is only an issue when an identifier is being declared,
since when the identifier is *used*, a positive dependency is noted.
I also think this could only be an issue for non-local declarations,
since otherwise the duplicate definition will be caught.
and any declaration of an identifier must probably depend on
either any previous declaration in scope or on the absence of a previous
declaration.
Again, I think only an issue for local declaration.
These are the kind of nasty corner cases that we will need to think
about, but I don't see them as a priority, since I don't think
they'll happen in real code, buggy or not.
Is there any prior art for this in other compilers, and if so can you
point to their documentation for what dependencies are handled and how?
Daniel Berlin mentioned some similariies with CodeStore, a persistent
code cache/database used by Montana, an incremental C++ compiler (used
in VisualAge for C++). Google "montana codestore" finds stuff I should
look at.
This is an area where seeing the testsuite for the dependency handling
would be more useful at this point than the source code for an
implementation of it.
Hm. I guess I need to learn how to write such tests in an
other-than-ad-hoc manner.
--
--Per Bothner
per at bothner dot com http://www.bothner.com/per/