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/