[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fundamental design issues (long message)

This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.

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
per@xxxxxxxxxxx   http://per.bothner.com/