RFR: JDK-8244592 Start supporting SOURCE_DATE_EPOCH

[Erik Joelsson]

Looks good.

What tools do we know are picking up this variable today?

/Erik

On 2020-05-07 07:29, Magnus Ihse Bursie wrote:
> As a part of the effort of creating a reproducible build, the build 
> system should know about SOURCE_DATE_EPOCH and allow it to be set 
> using different methods.
>
> This fix is needed to unblock JDK-8241616. With this patch, the 
> SOURCE_DATE_EPOCH variable will be available in the environment during 
> the build.
>
> I have added two options, --with-source-date and 
> --enable-reproducible-build. The former controls what value 
> SOURCE_DATE_EPOCH will get. The latter is a currently just a 
> placeholder, but my intention is to continue adding functionality for 
> making reproducible builds. (The reason that you might not always want 
> to have reproducible builds enabled is that, for instance, one thing 
> reproducible builds will do is set the timestamp for all created 
> files, and this is not generally a good idea.) The idea is still that 
> build changes that result in reproducible builds should be enabled 
> always, if there is no downside to them.
>
> If --with-source-date is specified on the command line, 
> --enable-reproducible-build will be turned on by default, otherwise it 
> will be turned off.
>
> The --with-source-date option takes either a keyword option, an 
> integer option, or a date/time string.
> * If "updated" is specified (this is also the default), 
> SOURCE_DATE_EPOCH will be set to the time when make is run.
> * If "current" is specified, the value is "hard-coded" to the time 
> when configure was run.
> * If "version" is specified, the value is from DEFAULT_VERSION_DATE in 
> make/autoconf/version-numbers is used. (This is probably not as good 
> an idea as it might sound, but it can be used as a simple way to get 
> the same value between different runs/points in time of the source 
> code, but for the same version.)
> * If an integer is used, that very number is used as the epoch-based 
> timestamp.
> * And finally, if an ISO-8059 date string (like "2020-05-07") is used, 
> it will be converted to a timestamp. (On systems with GNU date, the 
> parsing of the string is rather forgiving, on other systems (read: 
> macOS) it will be more strict.)
>
> Finally, this patch carries two unrelated changes.
> * In make/autoconf/jdk-version.m4, I noticed an error with the bash 
> regexp (which I used as starting point for parsing the timestamp 
> number). It would have accepted e.g. "123banana" as a number, but not 
> 000 (even though 001 was accepted).
> * In UTIL_ARG_ENABLE, I added a new argument IF_NOT_GIVEN. In the end, 
> I did not need this, but I still think the functionality is worth 
> keeping.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8244592
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8244592-add-SOURCE_DATE_EPOCH/webrev.01
>
> /Magnus