RFR: JDK-8244592 Start supporting SOURCE_DATE_EPOCH

[Magnus Ihse Bursie]

On 2020-05-07 17:34, Erik Joelsson wrote:
> Looks good.
>
> What tools do we know are picking up this variable today?
gcc will use it when replacing the __DATE__ and __TIME__ macros. [1] I 
know of no other tools that use it, but that might just be my limited 
knowledge. That's the reason I used "updated" as the default method, to 
set it to the time of building, which would minimize any differences 
produced by tools.

/Magnus

[1] https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
>
> /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