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.

Reply via email to