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.

[1] 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

[2] 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.

[3] Changing a function's body code -- in contrast to its declaration  
-- requires only the current C file to be recompiled.

[4] 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.