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

On 12/14/2015 03:31 PM, Dhole wrote: The copyright assignment process is now complete :) Let me know if I'm required to do anything else regarding the patch I sent. Right now we're in a bug fixing stage; please wait until stage 1 reopens and then resend your patch. Bernd

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

Hi, The copyright assignment process is now complete :) Let me know if I'm required to do anything else regarding the patch I sent. Best regards, Dhole

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

On 11/19/2015 04:35 PM, Dhole wrote: > On 11/17/2015 12:26 AM, Joseph Myers wrote: >> fprintf to stderr is never appropriate. All diagnostics should go through >> a diagnostic function that properly causes the message to be translated. >> >> If you want a fatal error (exit immediately after givin

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

On 11/17/2015 12:26 AM, Joseph Myers wrote: > fprintf to stderr is never appropriate. All diagnostics should go through > a diagnostic function that properly causes the message to be translated. > > If you want a fatal error (exit immediately after giving the message > rather than continuing co

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

Also, this environment variable needs documenting in cppenv.texi. -- Joseph S. Myers jos...@codesourcery.com

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

On Sun, 15 Nov 2015, Dhole wrote: > The error output in gcc/c-family/c-common.c (get_source_date_epoch) is > handled by an fprintf() to stderr followed by an exit (EXIT_FAILURE). I > am not sure this is the right approach for error handling, as I have > found many usages of the error() function in

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

On 11/16/2015 02:05 PM, Bernd Schmidt wrote: > On 11/15/2015 11:14 PM, Dhole wrote: >> gcc/c-family/ChangeLog: >> >> 2015-10-10 Eduard Sanou > > I can't find a previous change from you in the sources, so the first > question would be whether you've gone through the copyright assignment > process.

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

On 11/15/2015 11:14 PM, Dhole wrote: gcc/c-family/ChangeLog: 2015-10-10 Eduard Sanou I can't find a previous change from you in the sources, so the first question would be whether you've gone through the copyright assignment process. Bernd

[PATCH] Allow embedded timestamps by C/C++ macros to be set externally (2)

Hi! A while back I submitted a patch to the gcc-patches mailing list to allow the embedded timestamps by C/C++ macros to be set externally [0]. The attached patch addresses a comment from Joseph Myers : move the getenv calls into the gcc/ directory; and it also provides better organization and sty

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

On 06/30/2015 06:23 PM, Manuel López-Ibáñez wrote: > On 30 June 2015 at 17:18, Dhole wrote: >> 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, b

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

Since cpplib is a library and doesn't have any existing getenv calls, I wonder if it would be better for the cpplib client (i.e. something in the gcc/ directory) to be what calls getenv and then informs cpplib of the timestamp it should treat as being the time of compilation. -- Joseph S. Myer

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

On Jun 30, 2015, at 10:38 AM, Martin Sebor wrote: >> 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,

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

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

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

On 30 June 2015 at 17:18, Dhole wrote: > 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 bec

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 app

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

On 30/06/15 16:43, Manuel López-Ibáñez wrote: On 30/06/15 15:18, Dhole wrote: A solution for toolchain packages that embed timestamps during the build process has been proposed for anyone interested and it consists of the following: Perhaps this has been discussed and discarded before (if so I

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

On 30/06/15 15:18, Dhole wrote: A solution for toolchain packages that embed timestamps during the build process has been proposed for anyone interested and it consists of the following: Perhaps this has been discussed and discarded before (if so I would appreciate if you could point me to the

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

Hi! We are working in Debian —and I know other free software projects care— in providing our users with a way to reproduce bit-for-bit identical binary packages from the source and build environment. See for some rationale and further explanations