GPS Compiler options
in [ADA]
|
From: Simon Wright on 9 Apr 2010 13:20 Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes: > I think gnatmake -m corrects this problem. With this option, gnatmake > no longer relies on the timestamps but only on the CRC32 values in > the .ali files. I believe that it first compares the timestamps: if the same, no change, but if different, does the ali check.
From: Ludovic Brenta on 9 Apr 2010 13:46 Simon Wright wrote on comp.lang.ada: > Ludovic Brenta <ludo...(a)ludovic-brenta.org> writes: > > I think gnatmake -m corrects this problem. With this option, gnatmake > > no longer relies on the timestamps but only on the CRC32 values in > > the .ali files. > > I believe that it first compares the timestamps: if the same, no change, > but if different, does the ali check. Exactly. And gnatmake will then do the right thing (i.e. not recompile) if the timestamps are different only because the clocks of various machines are out of sync. -- Ludovic Brenta.
From: Simon Wright on 9 Apr 2010 17:00
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes: > Simon Wright wrote on comp.lang.ada: >> Ludovic Brenta <ludo...(a)ludovic-brenta.org> writes: >> > I think gnatmake -m corrects this problem. With this option, gnatmake >> > no longer relies on the timestamps but only on the CRC32 values in >> > the .ali files. >> >> I believe that it first compares the timestamps: if the same, no change, >> but if different, does the ali check. > > Exactly. And gnatmake will then do the right thing (i.e. not > recompile) if the timestamps are different only because the clocks of > various machines are out of sync. Indeed. But it takes much longer, because it has to open each file; and this is even worse over a network. GNAT 3.16a1 on Windows had a wonderful feature where the RTS timestamps were out by an hour unless you installed in daylight savings time! This led to opening all the relevant RTS files, every time, every compilation -- and to an interesting work instruction. |