[WORK] std.file.update function

[Andrei Alexandrescu via Digitalmars-d]

On 09/19/2016 01:16 AM, Walter Bright wrote:
> 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.

Great. In that case, if the target .o file already exists, it should be 
compared against the buffer. If identical, there should be no write and 
the timestamp of the .o file should stay the same.

I need to re-emphasize this kind of stuff is important for tooling. Many 
files get recompiled to identical object files - e.g. the many innocent 
bystanders in a dense dependency structure when one module changes. We 
also embed documentation in source files. Being disciplined about 
reflecting actual changes in the actual file operations is very helpful 
for tools that track file writes and/or timestamps.

> 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.

Interesting. What happens e.g. if one makes a change to a function whose 
generated code is somewhere in the middle of the object file? If it 
doesn't alter the call graph, doesn't the new .o file share a common 
prefix with the old one?

> 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.

This (and the subsequent considerations) is drifting off-topic. This is 
about getting a useful function off the ground, and sadly is 
degenerating into yet another off-topic debate leading to no progress.


Andrei