Update calendar for move to ports.

[imp]

Summary

calendar: implement #warning

Implement #warning so we can use it for migration to ports.

calendar: remove all datafiles except freebsd.

Keep the calendar.freebsd file, but remove all the other data
files. They are being replaced by the calendar-data package. Generate
files to install that have a #warning to advise people to install that
package. This keeps minimizes astonishment by giving a course of
action. People that install the port/package will never see them.

[imp]

Add generated files to the clean list.

[se]

I agree to the changes to the man-page, but have suggested changes to your proposal (see inline comments)

usr.bin/calendar/io.c

230–240

Please consider the alternative change that I suggested (to warn if the last path alternative has been used to locate the file, unless it is calendar.freebsd),
The change I suggested removes the need to patch the data files and the complications in the Makefile.
Only if the #warning was considered generally useful outside this context, I'd think it should be added as a new keyword.

usr.bin/calendar/pathnames.h

38 ↗

(On Diff #78692)

This is a regression - _PATH_LOCALBASE has been added to paths.h and I see no reason to re-introduce a written-out prefix here

[se]

On further thought: is it wise to have the man-page in FreeBSD base refer to the structure of the files installed by the calendar-data port?

I'd rather move this list to a man-page (calendar(5) or calendar-data(5) ???) and have only a short and general reference to the calendars provided by the port in the calendar(1) man-page.

[imp]

usr.bin/calendar/io.c

230–240

Yea, I'm still thinking that through. I did this stuff before I read your suggestion.

I'm not patching the files, I've removed them all entirely. I'm just generating all these files with #warning in case people pick them up. Though I haven't thought through all the implications for things like calendar.all (which now includes nothing but the warning). The plus side of this approach is that it's annoying, though maybe I want to generate #error instead and exit after the first one. The down side is if someone has their own calendar.all like file.

Another path forward would be to just remove the files, and hack the message from #include when it couldn't find the files to suggest installing calendar-data port/pkg instead if PREFIX "/share/calendar/calendar.all" was missing. Though people that don't run make delete-files wouldn't get rid of the stale files and might not update for a while (I go months or sometimes years between runs of that). Though just removing the files and having your hack would catch the case where we didn't run make delete-files.

I'd only keep the files like this, btw, through 13.0 then remove them in the 13 and current branches, their job being done.

In any event, I'll think things through a little on this topic.

usr.bin/calendar/pathnames.h

38 ↗

(On Diff #78692)

yea, this is junk so I can compile w/o that in my paths.h. I'll remove it.

[imp]

In D26926#600826, @se wrote:

On further thought: is it wise to have the man-page in FreeBSD base refer to the structure of the files installed by the calendar-data port?

I'd rather move this list to a man-page (calendar(5) or calendar-data(5) ???) and have only a short and general reference to the calendars provided by the port in the calendar(1) man-page.

I thought of that too. We already reference the port for the Jewish calendar and I wasn't sure how to include it in the port. But if you have a way, then send a pull request for calendar-data and I'll rework the wording in the man page.

[imp]

After careful consideration and a good stout, I'll update this as follows;
remove #warning and the associated man page update.
Remove all makefile junk and all the files removed (leaving just calendar.freebsd)
update the man page to point to the calendar-data port and calendar-data(5) assuming that it will be in that port shortly.
when we can't open a file, and the new /usr/local/share/calendar directory isn't present, add a warning about installing the calendar-data port
Add all these removed files to the ObsoleteFiles.inc file
Add a brief UPDATING entry
Bump __FreeBSD_version (unless someone else bumps it before I can get this committed)

This is the simplest and doesn't suffer from the need to special case the calendar.freebsd file. If people haven't updated to remove these files, it fails safe with the stale files (just like other areas of the system when users fail to run make delete-old-files). If users update and delete the files, they know what to do. If they have installed the port, it just works. It also minimizes long-term maint and a requirement to re-do anything after 13 to cleanup all the #warning files the solution up for review prior to this comment would have required. This entirely punts on the calendar.all stuff, but I think it's OK to punt that to the calendar-data package.

Sounds like a lot, but really it's 10 minutes of work.

[imp]

update

[se]

I agree that the test for the existence of the port provided data is the best solution, especially since it does not special case calendar.freebsd.