When sphinx-build is invoked without the -d command line switch, the
default path to the directory in which cached environment and doctree
files are placed is OUTPUTDIR/.doctrees. This causes the contents of
such cache directories to needlessly be included in BIND release
directories. Avoid that by employing the -d command line switch to make
each sphinx-build process use a cache directory outside the output
directory. Make sure these cache directories are separate from each
other as well, to prevent multiple sphinx-build processes running in
parallel from interfering with each other.
In order to prevent documentation building issues from being glossed
over, pass the -W command line switch to all sphinx-build invocations.
This causes the latter to return with a non-zero exit code whenever any
Sphinx warnings are triggered.
(cherry picked from commit 51479ed9a3)
The release notes were previously built as a separate document
(including the PDF version). It was agreed that this doesn't make much
sense, so the release notes are now included only as an appendix to the
BIND 9 ARM.
(cherry picked from commit 8eb2323ec3)
BSD sed does not recognize \s as a whitespace matching token. Make the
sed script in doc/arm/Makefile.in which ensures GitLab identifiers are
not split across lines portable by replacing \s with [[:space:]].
(cherry picked from commit b25e6b51f6)
- Merge release notes from all 9.15.x releases, leaving only those
which do not apply to BIND 9.14.
- Add missing GitLab/RT issue identifiers.
- Update "Introduction", "Note on Version Numbering", and "End of
Life" sections with BIND 9.16 information.
GitLab issue and merge request numbers placed in release notes (in the
form of "#1234" for issues and "!5678" for merge requests) should not be
split across two lines. Extend the shell pipeline generating
doc/arm/notes.txt with a sed invocation which prevents such splitting.
Intertwining release notes from different BIND releases in a single XML
file has caused confusion in the past due to different (and often
arbitrary) approaches to keeping/removing release notes from older
releases on different BIND branches. Divide doc/arm/notes.xml into
per-version sections to simplify determining the set of changes
introduced by a given release and to make adding/reviewing release notes
less error-prone.
to determine the paths to the various SGML and XML tools and files.
You should have a complete SGML catalog in /usr/local/share/sgml/catalog;
this will be picked up by the configure script and used for both the
ARM and the man pages.