[Pkg-pascal-devel] [Core] fpc and reproducible builds
Sven Barth
pascaldragon at googlemail.com
Mon Nov 2 16:31:19 UTC 2015
On 02.11.2015 11:37, Abou Al Montacir wrote:
>> Yesterday, I created the wiki page² about reproducible issues with ppu
>> files. The issue is that fpc stores the date of the source file of a ppu
>> into the ppu file. Looking at it, however, I am unsure if this timestamp
>> is actually really used. You don't need the source to use the ppu,
>> rigth? Does anybody know this? Abou? Otherwise, if somebody (Michalis
>> maybe) could test if updating the timestamp of the source of an ppu
>> (e.g. by using touch) after the ppu is build but before it is used
>> causes any issues?
> In the old days where the computers where too slow, Borland introduced
> the time stamp as a way to avoid recompiling. This was a feature
> borrowed from make utility that was considered too complex for common
> programmers (and is actually if you look in industrial world).
>
> Later, FPC introduced SHA computation as a more accurate way to check
> for modification, especially for the case where only implementation is
> changed but not the interface. This avoids recompiling all units
> depending on the changed one as only the link needs to be done again.
>
> Now, is that date still used or not, I don't know. That is why I copy
> here the FPC core team, in case someone can comment on that.
The date is still used to avoid recompilation since the CRC (not SHA)
approach requires to reparse the interface declaration which can be
costly to parse as well. Because of this a reparsing is only done if the
source file's timestamp is different compared to the one stored in the
PPU (this also includes include files). This mechanism is also used for
the WPO response file (which is referenced in the PPU as well) if Whole
Program Optimization is enabled.
>> If the date in the ppu is not critical, I am going to propose a patch to
>> upstream to honor the environment variable SOURCE_DATE_EPOCH³. I will
>> include an improved patch for the documentation issues then as well, so
>> that we don't need to carry Debian specific patches for long.
> That sound to me the right way, but would prefer hear a comment from FPC
> core team to avoid divergence in the future.
IMHO it's better to do this on your side (don't forget that we also
support compilation on slower systems like DOS, Amiga or MacOS Classic).
It should be enough to set all source files to a specific date before
building (in your case probably SOURCE_DATE_EPOCH) and then build.
>> Thanks for your help.
>> Paul
>> P.s. I am working on getting ppudump functionality into diffoscope, the
>> tool used by the reproducibility project to view differences.
> I was not aware of such tool, will have a look at it.
Just in case: from 3.0.0 on (or already 2.7.1 if you provide such
packages) ppudump supports output as XML or JSON using command line
parameters -Fx or -Fj respectively.
Regards,
Sven
More information about the Pkg-pascal-devel
mailing list