After GCC 15, C23 became the default version. [1]
Add a proper compiler test for constexpr support to ensure that GCC 15+
invoked with `c_std` set to `none` does not erroneously use the
constexpr shim.
This change does not affect the build in its default configuration
(which uses GNU C11); it is only meant to prepare the build system for
adding C23 elements to the code.
[1]: https://gcc.gnu.org/gcc-15/changes.html
The `<isc/bit.h>` header is a GNU C11 compatible version of C23's
`<stdbit.h>`.
It currently uses either `<stdbit.h>` or the equivilent compiler
builtins. However, the generic `__builtin_ctzg` and `__builtin_ctlz`
builtins are not available in every compiler version and thus falls
back to manually selecting from type.
Furthermore, the ctz fallback has been removed since `__builtin_ctzll`
has been used for a while directly without any compilation issues from
users. Thus, we can also require `__builtin_ctz`.
Unlike the rest of C23's bit utilities, we avoid the stdc_rotate_*
functions since we don't need the rotation modulus precision. This adds
a couple (admittedly cheap) unwanted instructions on some architectures.
When in developer's mode, make the DNS_TYPEPAIR_* macros be more
strict on the contents of the 'base' and 'covers', so we can catch
invalid use of the API.
Add a new CI job that checks whether all meson.build files in the
repository are formatted in the exact same way as "muon fmt" would
format them. This enforces formatting consistency across all
meson.build files in the repository and enables updating their contents
using dedicated tools, e.g. "meson rewrite".
Dynamically loadable libraries all use the `.so` extension on
BIND9-supported platforms, except for macOS. Export the dynamic library
extension of the current build platform in the generated `config.h`
file, in order to let the plugin code building plugin path based on a
simple plugin name. (which then would be platform-independent)
Plugins are built as shared libraries and are therefore installed into
$libdir/bind. Meanwhile, the build system sets the NAMED_PLUGINDIR
preprocessor variable to $datadir/bind instead. This prevents loading
plugins specified in the configuration file using just the shared
library name (i.e. without using an absolute path or a relative path).
Fix by setting NAMED_PLUGINDIR to the path that plugins are actually
installed into.
Commit 5c9b4f3163e05f64b97d04cba2c17ef59d682830 inadvertently broke
cross builds by making Meson process the doc/misc/meson.build file even
when sphinx-build is not found in PATH. The doc/misc/meson.build file
defines targets that require a non-native executable, cfg_test, in order
to be built.
Fix by reverting to only processing the doc/misc/ subdirectory when
sphinx-build is found in PATH and moving the relevant alias_target()
method call so that the build targets depending on a non-native
executable are only defined if sphinx-build is found in PATH.
The util/meson-dist-package.sh script hardcodes the date it is run on
into the man pages it creates in the dist tarball. This causes pkgdiff
to report discrepancies if the util/release-tarball-comparison.sh script
is run on a different day than the one the dist tarball was generated
on.
Fix by using the exact same solution as in BIND 9.20: generating the man
page stubs with a @RELEASE_DATE@ placeholder instead of a specific date
and only replacing that placeholder with a specific date during the
build process.
The 'plain' optimization level doesn't add any flags and gives the
control to the packager. Similarly, avoid any hardening flags in this
level.
Necessary flags such as `-fno-delete-null-pointer-checks` and
`-fno-strict-aliasing` are still included.
Building and installing from a git release installed all manpages
unconditionally even if binaries like dnstap-read were disabled and not
built.
Now the manpage configuration checks for such cases and also cleans up
remaining artifacts and unnecessary pages if the build directory is
reconfigured.
When building from the tarball, meson would try to install both
sphinx-built and template configured manpages.
While harmless for now, it might cause issues for future meson version.
Meson generated 'dnssec-validation yes' into the built-in config, but
this config without an explicit trust anchor does not enable validation.
Change default to 'dnssec-validation auto' to use built-in key, as in
the autotools days.
The meson build switched to generating the file grammars and using meson
to build the manpages/ARM. This is because meson doesn't work well when
writing files outside the build directory.
However, this has been suboptimal when someone only wants to build the
documentation (like RTD). Sphinx can now be used outside meson like it
was with autoconf.
Grammars are now updated by the developer with CI checking if one is
needed or not, like clang-format.
The add_project_dependencies() method was only added in Meson 0.63.
Replace its only use in meson.build with a corresponding call to the
add_project_link_arguments() method to avoid bumping the minimum
required Meson version beyond the one available in stock Ubuntu 22.04
LTS repositories.
Use the links() method instead of compiles() for checking whether
-latomic needs to be added to linker invocations as compiles() does not
perform the linking step and is therefore not appropriate for carrying
out this kind of checks.
named-compilezone is an alias for named-checkzone: the two tools are
built from the same set of source files, but they behave differently
depending on which executable gets invoked. With Automake,
named-compilezone was installed as a hard link to named-checkzone using
a custom installation hook; try to keep things simple with Meson by
using the install_symlink() method, which makes named-compilezone a
symbolic link to named-checkzone and is the same thing that is already
used for ddns-confgen/tsig-keygen.
move the "makejournal" tool from bin/tests/system to bin/tools
and rename it to "named-makejournal". add a man page. update
tests to use the new file location.
Meson is a modern build system that has seen a rise in adoption and some
version of it is available in almost every platform supported.
Compared to automake, meson has the following advantages:
* Meson provides a significant boost to the build and configuration time
by better exploiting parallelism.
* Meson is subjectively considered to be better in readability.
These merits alone justify experimenting with meson as a way of
improving development time and ergonomics. However, there are some
compromises to ensure the transition goes relatively smooth:
* The system tests currently rely on various files within the source
directory. Changing this requirement is a non-trivial task that can't
be currently justified. Currently the last compiled build directory
writes into the source tree which is in turn used by pytest.
* The minimum version supported has been fixed at 0.61. Increasing this
value will require choosing a baseline of distributions that can
package with meson. On the contrary, there will likely be an attempt
to decrease this value to ensure almost universal support for building
BIND 9 with meson.
