This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/2] Allow to override build date with SOURCE_DATE_EPOCH
- From: Nick Clifton <nickc at redhat dot com>
- To: "Bernhard M. Wiedemann" <bwiedemann at suse dot de>, binutils at sourceware dot org
- Cc: Linda Zhang <lindasc at qq dot com>
- Date: Mon, 5 Nov 2018 17:29:07 +0000
- Subject: Re: [PATCH 2/2] Allow to override build date with SOURCE_DATE_EPOCH
- References: <20181026055927.23012-1-bwiedemann@suse.de> <20181026055927.23012-2-bwiedemann@suse.de>
Hi Bernhard,
This helps making xen efi binaries build reproducibly by default
much more elegantly than
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01850.html
+ {
+ time_t build_time;
+ const char *source_date_epoch = getenv ("SOURCE_DATE_EPOCH");
+ if (source_date_epoch == NULL
+ || (build_time = strtoll (source_date_epoch, NULL, 10)) <= 0)
+ build_time = time (0);
+ H_PUT_32 (abfd, build_time, filehdr_out->f_timdat);
+ }
I *really* don't like this solution to the problem. There are several
reasons:
* There is no documentation on this environment variable, so
users are not going to know that it exists.
* There is already a well established way of customizing the
behaviour of the linker: command line options.
* Possibly the most important: It is really hard to debug problems
reported by users when there are environment variables controlling
the behaviour of the program. Most users will not even bother to
include the environment variables in the bug report, and even if
they do, they could be misleading if the build system involved
overrides these variables for its own purposes.
My suggestion would be to modify the already existing --insert-timestamp
option, so that it can take an option argument specifying the time to be
inserted. That ought to work and would, in my opinion, be much better
than using environment variables.
Cheers
Nick