Jon Turney wrote:
On 16/02/2024 12:29, Christian Franke via Cygwin-apps wrote:
Fail if it is out of range. Warn if it lies in the future. Inform
whether it is set or set but not exported.
What is the valid range here?
The range accepted by 'date -d @EPOCH ...', later used to adjust the
patch timestamps.
The test could also be removed as date interestingly accepts a (too)
wide range of values :-)
$ date -d @$((1<<55))
Sun Jun 13 08:26:08 CEST 1141709097
$ date -d @$((1<<56))
date: time ‘72057594037927936’ is out of range
$ date -d @$((-(1<<55)))
Sun Jul 20 18:27:20 LMT -1141705158
$ date -d @$((-(1<<56)))
date: time ‘-72057594037927936’ is out of range
Would it not make more sense to just re-export it if set?
If the cygport file decides to set but not export it, there is possibly
no need to do it. An example is smartmontools.cygport which passes the
unexported variable as a parameter to configure.
(so that commands like "SOURCE_DATE_EPOCH=something cygport foo" work
as expected?)
Would make no difference as the 'VAR=val CMD...' syntax already exports
the variable to the CMD:
$ unset FOO; FOO=bar sh -c 'sh -c "sh -c printenv\ FOO"'
bar
