On Thu, Apr 28, 2016 at 08:29:56PM +0200, Dhole wrote:
> There is the Wdate-time flag, that warns on using __DATE__, __TIME__ and
> __TIMESTAMP__. Although that alone will not make the compilation fail
> unless it's used with Werror.
>
> The reason behind using fatal_error (rather than a warning) when
> SOURCE_DATE_EPOCH contains an invalid value is due to the
> SOURCE_DATE_EPOCH specification [1]:
>
> SOURCE_DATE_EPOCH
> (...)
> If the value is malformed, the build process SHOULD exit with a non-zero
> error code.
First of all, using error instead of fatal_error achieves just that too,
except that it allows also detecting other errors in the source.
fatal_error is meant for cases where there is no way to go forward with the
compilation, while here exists a perfectly reasonable way to go forward (assume
the env var is not set, use a hardcoded timestamp, ...).
> And the reason for reading and parsing the env var in gcc/ rather than
> when the macro is expanded for the first time (in libcpp/) is from a
> comment by Joseph Myers made the first time I submited this patch [2].
> The most clean way to read the env var from gcc/ I found was to do it
> during the initialization. But if you think this should be done
> different I'm open to change the implementation.
Doing this on the gcc/ side is of course reasonable, but can be done through
callbacks, libcpp already has lots of other callbacks into the gcc/ code,
look for e.g. cpp_get_callbacks in gcc/c-family/* and in libcpp/ for
corresponding code.
> Bernd: I'll see if I can prepare a testcase; first I need to get
> familiar with the testing framework and learn how to set environment
> variables in tests. Any tips on that will be really welcome!
grep for dg-set-target-env-var in various tests.
Jakub
