configure: more nuanced time_t treatment.

I'm taking the position that on systems where time_t is 32
bits by default, but can be switched to 64 with some option
that we positively detect, configure will refuse to run unless
the user explicitly chooses what to do using either --big-time
or --no-big-time. We neither want to ignore this situation
(because Y2038 is a problem, and we don't want to contribute
to it) nor do we want to force 64 bit time_t, which could be
problematic in distributions where other applications and
components are not being configured that way for whatever
reason (like it being a system with a projected life span that
is not expected to go past Y2038).

* configure (big_time, big_time_given): New variables.
(help): Document big-time. New logic in the test to validate
the detected situation versus whether or not the big-time
variable has been specified, and which way. Error out in
several cases.

0 files changed, 0 insertions, 0 deletions