|speeding up compile times in C++ email@example.com (1995-01-26)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-01-26)|
|Re: speeding up compile times in C++ email@example.com (1995-01-29)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-02)|
|Re: speeding up compile times in C++ email@example.com (Steve Glass) (1995-02-03)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-04)|
|Re: speeding up compile times in C++ email@example.com (Ronald F. Guilmette) (1995-02-04)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-06)|
|Re: speeding up compile times in C++ email@example.com (Anthony T. Green) (1995-02-06)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-08)|
|[1 later articles]|
|From:||email@example.com (Shankar Unni)|
|Organization:||Silicon Graphics, Inc.|
|Date:||Thu, 2 Feb 1995 22:24:35 GMT|
Amir Michail (firstname.lastname@example.org) wrote:
> The idea is for the compiler to maintain a .i file along with any .h file
> that gives information about how the .o files were created. In
> particular, if I declare a structure taking x bytes, then the compiler
> generates code that gives the structure 2x bytes.
> Now, if I change the structure later on by reordering variables, adding
> and/or deleting variables, then the compiler checks the .i file to see how
> the .o files were created, and automatically reorders items or pads
> structures in the .h file so that the ordering of old items is identical
> to that in the .o file. Thus, previously compiled code will still work
> with new code compiled with the new .h file. Obviously, if the structure
> grows to twice its original size, then all .c files that depend on the .h
> file must be recompiled with twice the new size of the structure.
This is almost exactly the set of ideas behind SGI's Delta/C++ compiler,
and its Smart Build feature.
The code is generated in such a way that if you make a set of "compatible"
changes (which actually include adding members or base classes, reordering
members, overriding virtual member functions, etc), the only code that has
to be recompiled is the one where the class' virtual table is emitted. All
other code need not recompile (or even re-link, if the changed class is in
a shared library). The runtime environment (shared library loader, etc)
will fix things up automatically.
The Smart Build feature works hand-in-hand with this, creating binary
precompiled headers for each header file, and when a header changes, it
notes in the new precompiled header the differences between this version
and the last one: that way, even if you issue a "make" command, the compile
commands which are issued usually complete in a second or so, which means
that large trees can be "recompiled" in a matter of a few minutes.
Shankar Unni E-Mail: email@example.com
Silicon Graphics Inc. Phone: +1-415-390-2072
Return to the
Search the comp.compilers archives again.