bear wrote:

> Now, for the luxury of not having to actually write the
> forward declarations and manually keep them in sync with
> the source code, that might be worth it.  But there's a
> deeper issue that messes up the compile-farm model; how
> do I detect when the autogenerated forward-declaration
> resources have become stale?  Since they're autogenerated
> from source code, a simple dependency model indicates that
> they become stale when the associated source code changes.
> But that means that *EVERY* change in the source for a
> module results in a new forward-declarations resource for
> that module, and that triggers a recompile of *EVERY*
> module that calls anything in the changed module. The
> development of large projects thrashes to a halt as all
> the developers run screaming.

When you compile libraryX you generate a compilation result
(bytecode, assembler, or maybe just a distillation of the
source).  You also get a "abstract" which is the "forwards-
declaration resource" you mention.  Other libraries that
import moduleX only use its abstract file.  To avoid a
needless cascase of recompilations, the trick is when
compiling libraryX you only update its abstract if it has
changed from the pervious version.  Alternatively, you
reset it's timestamp to an earlier version if it hasn't
changed.  Then moduleY only needs to be recompiled if
moduleX's abstract has changed, not for any change to moduleX.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/