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)
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)
- "--with-geoip" is used to enable the legacy GeoIP library.
- "--with-geoip2" is used to enable the new GeoIP2 library
(libmaxminddb), and is on by default if the library is found.
- using both "--with-geoip" and "--with-geoip2" at the same time
is an error.
- an attempt is made to determine the default GeoIP2 database path at
compile time if pkg-config is able to report the module prefix. if
this fails, it will be necessary to set the path in named.conf with
geoip-directory
- Makefiles have been updated, and a stub lib/dns/geoip2.c has been
added for the eventual GeoIP2 search implementation.
(cherry picked from commit fea6b5bf10)
(cherry picked from commit 6a7e805796)
Make will choose modified manual from build directory or original from source
directory automagically. Take advantage of install tool feature.
Install all files in single command instead of iterating on each of them.
(cherry picked from commit 88f913ac81)
4826. [cleanup] Prevent potential build failures in bin/confgen/ and
bin/named/ when using parallel make. [RT #46648]
(cherry picked from commit a573b93b46)
4503. [cleanup] "make uninstall" now removes file installed by
BIND. (This currently excludes Python files
due to lack of support in setup.py.) [RT #42912]
(cherry picked from commit 6087f87afb)
Tinderbox UserandMichał Kępień
Michal Nowak
Evan Hunt
Ondřej Surý
Petr MenšíkandMark Andrews
Ondřej Surý
Francis Dupont