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/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

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

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

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

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

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

[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

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 dh...@openmailbox.org 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

[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 https://wiki.debian.org/ReproducibleBuilds/About for some rationale and further explanations.

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

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

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

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 Jun 30, 2015, at 10:38 AM, Martin Sebor mse...@gmail.com 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

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

On 30 June 2015 at 17:18, Dhole dh...@openmailbox.org 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

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.