|Semantic difference of source files firstname.lastname@example.org (Michiel) (2008-08-17)|
|Re: Semantic difference of source files email@example.com (Michiel) (2008-08-17)|
|Re: Semantic difference of source files firstname.lastname@example.org (Barry Kelly) (2008-08-18)|
|Re: Semantic difference of source files DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-08-18)|
|Re: Semantic difference of source files email@example.com (glen herrmannsfeldt) (2008-08-18)|
|Re: Semantic difference of source files firstname.lastname@example.org (glen herrmannsfeldt) (2008-08-19)|
|Re: Semantic difference of source files email@example.com (Marco van de Voort) (2008-08-20)|
|Re: Semantic difference of source files firstname.lastname@example.org (glen herrmannsfeldt) (2008-08-20)|
|Re: Semantic difference of source files DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-08-23)|
|[3 later articles]|
|From:||Barry Kelly <email@example.com>|
|Date:||Mon, 18 Aug 2008 03:51:44 +0100|
|Posted-Date:||19 Aug 2008 19:06:01 EDT|
> You see, all automatic building utilities I know (make, ant, jam)
> use only the modification date of a source file to decide whether or
> not to recompile it and its reverse dependencies. For this reason,
> many programming languages encourage the programmer to separate
> their interfaces and implementations either textually or by using
> different files.
Delphi does not use separate interface and implementation files, and
incorporates its own make logic. However, the make logic still uses
timestamps to determine when to rebuild, because line information and
other implementation details may have changed, and thus debugging would
A larger part of the problem with C, C++, and, for very large
assemblies, C#, is that they rely on parsing large numbers of files for
a single compilation. In the case of C & C++, header files; in the case
of C#, all source files making up the assembly / module.
Delphi avoids these problems by having a intermediate-file compilation
strategy like C & C++, but storing the interface information in the
intermediate file itself.
The problem isn't particularly acute with C#, or Java, for that matter,
because they have working module systems - albeit primitive (though I
don't claim that Delphi is better in this respect).
> I propose that in addition to comparing modification dates, we selectively
> compare AST's (if the source file is newer). At the very least this allows
> the programmer to modify style, layout and comments without requiring any
> recompilation at all. If the comparison utility is smart enough, you may
> even perform trivial refactoring without losing semantic equivalence.
Delphi solves this problem by computing symbol versions for all exported
symbols, and storing symbol versions alongside exports.
Symbol versions are just hashes whose algorithms are specific to the
kind of symbol.
However, these symbol versions are only used for validating link-time
integrity, not for dependency-checking. In other words, we try to make
sure that it's impossible to get a silent link-time mismatch and
consequent crash at runtime.
> * You need to save a representation of the AST when compiling. This is, I
> believe, a low price to pay. Perhaps it could even be attached to the
> result file as a sort of meta-data.
Oddly enough, Delphi also stores representations of selected ASTs in
object files in order to support generics (very roughly equivalent to
C++ template export). These ASTs are stored as binary blobs and the
blobs themselves versioned in a binary fashion, after making all line
number info in the AST relative.
(I work for CodeGear, a division of Embarcadero Tech., on the Delphi
Return to the
Search the comp.compilers archives again.