[WORK] std.file.update function

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 18 22:16:37 PDT 2016


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.


More information about the Digitalmars-d mailing list