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
without influencing the object file (e.g. documentation, certain style
unittests in non-unittest builds etc) there'd be no linking upon
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
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.