[tz] make error

[Philip Paeps]

On 2023-11-18 03:20:41 (+0800), Paul Eggert via tz wrote:
> On 2023-11-17 00:30, Robert Elz wrote:
>> future version probably ought to be
>> rather distant future, not next year sometime (or even the next few 
>> years
>> after that).
>
> Good point. From what we know now, 2029 might be a good year to do it, 
> as RHEL 7 ELS ends June 2028. I installed the attached proposed patch. 
> We can of course delay until after 2029 as more info becomes known.

I think it's reasonable to expect everyone to have a C99 compiler by 
2029.  The standard will turn 30 years old that year.  Even the most 
tenacious long-term support systems will have run out of support by 
then.  Moreover: the poor souls stuck with maintaining those systems 
will have ample experience installing newer compilers on them.

Nobody will accuse the tz project of being hasty.  Especially since 
we're giving 5+ years notice.

>> It might be worth adding a "common issues" file
>
> Yes, GNU Emacs does something like this, with its etc/PROBLEMS file 
> (currently 4412 lines).
>
> Currently TZDB puts this sort of thing in Makefile, which discusses 
> the C89 issue along with dozens of similar porting issues. Evidently 
> Makefile isn't always being read; this is not surprising as it has 
> hundreds of lines of comments.
>
> Not sure that a separate PROBLEMS file (which would also have hundreds 
> of lines) would always be read either. To some extent we'll always be 
> stuck getting email saying "this doesn't work for me" by people who 
> haven't had time to read the relevant documentation, regardless of 
> where that documentation is.
>
> For what it's worth, the Emacs etc/PROBLEMS file contains a long list 
> of problems most of which nobody ever runs into nowadays, and hardly 
> anybody reads the file.

I agree that a separate file pointing out PROBLEMS won't encourage 
anyone to read it.  Guy's suggestion, elsewhere in this thread, to add a 
pointer to the Makefile in the README is a good idea.  At least README 
has a fighting chance of being read ... the clue is in the name. :-)

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises