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
