Brian Stevens wrote: > Robert Covington wrote: > >> FBToC's build/translation exclusion engine seems flawed, not >> intelligent enough, and seems to re-translate files that are not >> even changed. > > RP is the guru in this area, so hopefully he will chime in. AFAIK, > at least the compile ( and I believe the translation ) is smart > enough to NOT translate files that haven't changed. The 'exclusion engine' first appeared in FBtoC 1.1.9, released in February 2009. Dependency analysis (figuring out which files to compile) must exclude every possibility of linking stale code, to avoid link-time errors or worse. It must guarantee that the linked executable is identical to one obtained by compiling everything. Here is how FBtoC's dependency analysis operates.  A change in any of the following kinds of declarations requires recompilation of all subsequent translated code: global variable begin record ... end record #define function name and type, and parameter names and types  Changing a _constant's value requires recompilation only of code that mentions the _constant, except that if a mentions forms part of a declaration as in #1, all code subsequent to the declaration must be recompiled.  Changing a function's body code -- in contrast to its declaration -- requires only the current C file to be recompiled.  Certain changes do not force recompilation of anything: comments whitespace outside a string literal name of _constant toolbox statements declarations inside '#if def _DEFINEDINCARBON ... #endif' Here 'Change' means insertion, deletion, altered name, altered order, and so on. For efficiency in dealing with multi-file projects, FBtoC generally combines the translations of several FB files into one C file. Robert P.