This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Allow embedded timestamps by C/C++ macros to be set externally

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:
> (You only need to convince the
> decision-makers). I'm not one of them ;)

Thanks for the tip!


Best regards,

Attachment: signature.asc
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]