Recompile .m file if .o has same timestamp
Final Release Note
YottaDB recompiles a .m
source file to generate a new .o
object file if a source file and its corresponding object file (as matched by $zroutines
) have the same time stamp. Previously, YottaDB recompiled only if the timestamp of the matching object file was older than than of the source file. To avoid unnecessary recompilation, YottaDB ensures that a generated object file has a later timestamp than its source file. Previously, it was possible for both to have the same timestamp. [#385 (closed)]
Description
In internal testing, we had a rare test failure in the v63005/gtm8951 subtest where it turned out that temp.m and temp.o were created initially. Later temp.m was recreated with different content but it ended up with the exact same nanosecond-level timestamp (as shown by a ls --full-time) as temp.o. Later when the test did a $TEXT(^temp) (which is one of the commands that invoke Auto-ZLINK, see https://docs.yottadb.com/ProgrammersGuide/commands.html#auto-zlink), it should have recreated temp.o but did not. This is because if the timestamps between the .o and .m are identical, we do not recompile. But to avoid any potential inconsistencies like the above test failure, we need to recompile even in the identical case.
Recompiling always in the identical case might have other issues. For example, the .o file created as part of compiling a .m file could end up with the exact same timestamp as the .o depending on the underlying timestamp resolution of the file system. In that case, we will have to do yet another (unnecessary) recompile until the .o timestamp becomes more than the .m timestamp. Another example is if the .m and .o files are installed in a read-only directory, we will not have permissions to do the recompile. So recompile always is not desirable either.
A good compromise seems to be to compute the hash of the .m file as part of generating the .o file. And as part of doing the .m vs .o time check, if we notice the timestamps to be identical, we read the current .m file and recompute its hash to see if the hash stored in the .o file matches and if so we avoid the compilation. This will slow down general compilation slightly due to the increased cost of hash computation. But it is not considered noticeable.
Draft Release Note
ZLINK/DO/GOTO/ZBREAK/ZGOTO/ZPRINT/$TEXT recompile the .m file if they detect the .o file exists and has the same timestamp as the .m file but does not correspond to the .m file. Previously, they did not recompile if the timestamp matched which could result in confusing behavior.