Every DocBook source document can be namespaced (DocBook 5) or
non-namespaced (DocBook 4). The set of XSL stylesheets used for
producing an output document can also be namespaced or non-namespaced.
Namespaced source documents should be used with namespaced stylesheets
and non-namespaced source documents should be used with non-namespaced
stylesheets. However, both stylesheet flavors contain processing rules
which allow them to be used interchangeably for any type of source
document.
Unfortunately, these processing rules became broken in version 1.79.1 of
the stylesheets, which means that non-namespaced source documents can no
longer be correctly transformed into man pages using namespaced
stylesheets and vice versa. This problem was fixed upstream [1], but no
released version of the XSL stylesheets contains that fix yet.
Back in 2016, this problem was reported as RT #43831 and allegedly fixed
in commit 1b8ce3b330. However, that fix
only helped for the non-namespaced version of the stylesheets - while
also breaking man page generation for the namespaced flavor.
Since using namespaced DocBook sources is the current best practice
(DocBook 5), make BIND DocBook sources namespaced again. When using
version 1.79.1 or 1.79.2 of the XSL stylesheets, care must be taken to
ensure namespaced stylesheets are used for generating BIND
documentation.
[1] https://github.com/docbook/xslt10-stylesheets/issues/109
All our MSVS Project files share the same intermediate directory. We
know that this doesn't cause any problems, so we can just disable the
detection in the project files.
Example of the warning:
warning MSB8028: The intermediate directory (.\Release\) contains files shared from another project (dnssectool.vcxproj). This can lead to incorrect clean and rebuild behavior.
(cherry picked from commit b6c2012d93)
Our vcxproj files set the WarningLevel to Level3, which is too verbose
for a code that needs to be portable. That basically leads to ignoring
all the errors that MSVC produces. This commits downgrades the
WarningLevel to Level1 and enables treating warnings as errors for
Release builds. For the Debug builds the WarningLevel got upgraded to
Level4, and treating warnings as errors is explicitly disabled.
We should eventually make the code clean of all MSVC warnings, but it's
a long way to go for Level4, so it's more reasonable to start at Level1.
For reference[1], these are the warning levels as described by MSVC
documentation:
* /W0 suppresses all warnings. It's equivalent to /w.
* /W1 displays level 1 (severe) warnings. /W1 is the default setting
in the command-line compiler.
* /W2 displays level 1 and level 2 (significant) warnings.
* /W3 displays level 1, level 2, and level 3 (production quality)
warnings. /W3 is the default setting in the IDE.
* /W4 displays level 1, level 2, and level 3 warnings, and all level 4
(informational) warnings that aren't off by default. We recommend
that you use this option to provide lint-like warnings. For a new
project, it may be best to use /W4 in all compilations. This option
helps ensure the fewest possible hard-to-find code defects.
* /Wall displays all warnings displayed by /W4 and all other warnings
that /W4 doesn't include — for example, warnings that are off by
default.
* /WX treats all compiler warnings as errors. For a new project, it
may be best to use /WX in all compilations; resolving all warnings
ensures the fewest possible hard-to-find code defects.
1. https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2019
(cherry picked from commit 789d253e3d)
This fixes two scan-build false positives:
context.c:441:23: warning: The left operand of '!=' is a garbage value
|| sin.sin_port != htons(lwres_udp_port))
~~~~~~~~~~~~ ^
context.c:447:25: warning: The left operand of '!=' is a garbage value
|| sin6.sin6_port != htons(lwres_udp_port))
~~~~~~~~~~~~~~ ^
2 warnings generated.
The sin and sin6 structures are used as argument to recvfrom call and
they are properly filled by the call.
Until now, the build process for BIND on Windows involved upgrading the
solution file to the version of Visual Studio used on the build host.
Unfortunately, the executable used for that (devenv.exe) is not part of
Visual Studio Build Tools and thus there is no clean way to make that
executable part of a Windows Server container.
Luckily, the solution upgrade process boils down to just adding XML tags
to Visual Studio project files and modifying certain XML attributes - in
files which we pregenerate anyway using win32utils/Configure. Thus,
extend win32utils/Configure with three new command line parameters that
enable it to mimic what "devenv.exe bind9.sln /upgrade" does. This
makes the devenv.exe build step redundant and thus facilitates building
BIND in Windows Server containers.
(cherry picked from commit 0476e8f1ac)
Tinderbox UserandMichał Kępień
Michal Nowak
Evan Hunt
Mark Andrews
Ondřej Surý
Ondřej Surý