public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dhole <dhole@openmailbox.org>
To: gcc-patches@gcc.gnu.org
Cc: "Manuel López-Ibáñez" <lopezibanez@gmail.com>
Subject: Re: [PATCH] Allow embedded timestamps by C/C++ macros to be set externally
Date: Tue, 30 Jun 2015 15:42:00 -0000	[thread overview]
Message-ID: <5592B356.3080601@openmailbox.org> (raw)
In-Reply-To: <5592AC51.5040007@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On 06/30/2015 04:48 PM, Manuel López-Ibáñez wrote:
> On 30/06/15 16:43, Manuel López-Ibáñez wrote:
>> Perhaps this has been discussed and discarded before (if so I would
>> appreciate
>> if you could point me to the relevant discussion), why not simply
>> redefine
>> __DATE__ and __TIME__ to an appropriate string via the command-line or
>> a dummy
>> include?

I'm not aware of any previous discussion on the subject, but I'm also
interested in reading it in case it exists :)

In the debian reproducible builds project we have considered several
options to address this issue. We considered redefining the __DATE__ and
__TIME__ defines by command line flags passed to gcc, but as you say,
that triggers warnings, which could become errors when building with
-Werror and thus may require manual intervention on many packages.

We are trying to find a solution that can make as much packages build
reproducible as possible minimizing the amount of specific patches for
affected packages, and we believe such solution will benefit other
projects working on reproducible builds as well.

We propose to extend the env variable SOURCE_DATE_EPOCH to anyone
interested for this purpose. For instance, this feature has been
implemented upstream in help2man (1.47.1) [1], quoting the latest
changelog entry:
"""
  * Add support for reproducible builds by using $SOURCE_DATE_EPOCH as
    the date for the generated pages (closes: #787444).
"""

>> That probably triggers some warnings (or it may not be supported at
>> all, I
>> haven't tried myself), but fixing those issues leads to a more general
>> solution
>> than GCC reacting to an arbitrary variable name and changing its
>> behaviour
>> quite silently.

In case the fact that GCC changing its behavior silently is a concern,
we also discussed the possibility of enabling this feature with a flag
such as `--use-date-from-env`. Again, we are open to comments and other
ideas about this approach :)

> In any case, you should be aware of point 10 here:
> https://gcc.gnu.org/wiki/Community (You only need to convince the
> decision-makers). I'm not one of them ;)

Thanks for the tip!

[1] https://www.gnu.org/software/help2man/

Best regards,
Dhole


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2015-06-30 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 13:19 Dhole
2015-06-30 14:48 ` Manuel López-Ibáñez
2015-06-30 14:49   ` Manuel López-Ibáñez
2015-06-30 15:42     ` Dhole [this message]
2015-06-30 16:32       ` Manuel López-Ibáñez
2015-07-03 14:00         ` Dhole
2015-06-30 17:41       ` Martin Sebor
2015-06-30 18:30         ` Mike Stump
2015-06-30 23:21 ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5592B356.3080601@openmailbox.org \
    --to=dhole@openmailbox.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lopezibanez@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).