On 9/18/2016 8:20 AM, Andrei Alexandrescu wrote:
On 09/18/2016 11:17 AM, Andrei Alexandrescu wrote:
Simplest case is - source file is being changed, therefore a new object
file is being produced, therefore a new executable is being produced.
Forgot to mention a situation here: if you change the source code of a module
without influencing the object file (e.g. documentation, certain style changes,
unittests in non-unittest builds etc) there'd be no linking upon rebuilding. --
The compiler currently creates the complete object file in a buffer, then writes
the buffer to a file in one command. The reason is mostly because the object
file format isn't incremental, the beginning is written last and the body gets
backpatched as the compilation progresses.
I can't really see a compilation producing an object file where the first half
of it matches the previous object file and the second half is different, because
of the file format.
Interestingly, the win32 .lib format is designed for incredibly slow floppy
disks, in that updating the library need not read/write every disk sector.
I'd love to design our own high speed formats, but then they'd be incompatible
with everybody else's.