gprbuild: -s flag causes recompilation if timestamp changes

[ckankare]

With -s flag the timestamp of the file is written to the switches file, and is used when comparing the switches. This means that if the timestamp of the object file changes, by passing -s, it will always cause a recompilation.

This means that, at least, -m is not compatible with -s; as always then the timestamp has changed we will have a recompilation whether or not the checksum matches.

It feels a bit odd that the timestamp of the object file is considered a switch, and I would guess that the expectation would be that it is not. Maybe instead a checksum could be used.

[t-14]

Whether or not a timestamp should be taken into account is controlled by -m, -s is orthogonal. The two switches are perfectly compatible, if both -m and -s are specified then the timestamp is ignored -

$ touch a.ads
$ gprbuild -s -Pa -m
$ gprbuild -s -Pa
Compile
   [Ada]          a.ads

[ckankare]

Yes, I was incorrect that -m is incompatible with -s. I used touch for all files in the build folder and compared by not passing -s.

However, the timestamp is written to the switches file and compared with the timestamp of the object file when -s is used.

$ gprbuild -s -Pa -m
$ touch a.o
$ gprbuild -s -Pa -m
Compile 
   [Ada]          a.ads

Which is not the case when only using -m.

$ gprbuild -Pa -m
$ touch a.o
$ gprbuild -Pa -m

I have a case where the timestamp of the object file might change, but would rather want to continue to use the -s flag. And either way, storing a checksum instead of a timestamp with one second accuracy might be more sensible.

[t-14]

Yes, if it's the object's timestamp which changes, we invalidate the switches file since in this case we can't ensure that the object file was generated with the given switches.

Using a checksum in such cases might indeed be more sensible, and we will probably switch to checksum-based verification in the new version that we are working on.