There is no need to use our own option for this when an official
one exists. Even worse, on the current master, if we set ours to
on and the official one to OFF, the tests directory is included,
but the add_boost_test() command skips building/adding them, which
forces us to wrap additional calls to set_tests_properties() in
a check on the official option.
CMake 3.4 introduced a new policy [^1] which prevents from automatically
adding the compiler flags needed for exporting the symbols of the
executables and libraries without the `ENABLE_EXPORTS` property. So, by
defining this variable, CMake will restore the previous behaviour by
automatically adding the `ENABLE_EXPORTS` properties to all targets.
[1]: https://cmake.org/cmake/help/latest/policy/CMP0065.html
CMake version `< 3.5` is no longer supported, so the new CMake minimum
policy version is set to `3.8` to support C++17 unconditionally. After
checking all the policies that might affect Icinga 2 in any way, CMake
`3.17` is used as a max supported CMake policy. Anything above that may
work but we didn't explicitly verify the policies introduced with CMake
3.18 and later and may or may not affect Icinga 2.
`override` indicates an override of a virtual method and refuses to compile in case of a signature mismatch across the inheritence hierarchy.
This is especially useful when signatures change not to forget anything. Hence, we shall always use `override` whereever applicable.
to stick to CMake pre-v3.29 behavior. CMake v3.29 introduces CPACK_WIX_INSTALL_SCOPE. Its default conflicts with the ALLUSERS property in our icinga-installer/icinga2.wixpatch.cmake.
Unfortunately, the symbol resolution of boost::stacktrace is broken on
FreeBSD, therefore fall back to using backtrace_symbols() to print the
stack trace saved by Boost.
Additionally, -D_GNU_SOURCE is required on FreeBSD for the
_Unwind_Backtrace function used by boost::stacktrace.
Older versions of MSVC fail to rethrow an unhandled C++ exception (using
`throw;`) in the termination handler (`std::set_terminate`), however
Icinga relies on this behavior in its crash handler
(`Application::ExceptionHandler`).
On case-insensitive file systems (i.e. macOS), the VERSION file collides with the Boost-provided version file on #include <version>.
Work around by re-naming VERSION to ICINGA2_VERSION.
When statically compiling icinga2 with a local boost the order of the boost libraries matters.
Correcting the order fixes the following linker issue:
```
make[5]: Entering directory `.../icinga2/icinga2-2.11.3/build'
[ 98%] Linking CXX executable ../Bin/RELEASE/icinga2
.../boost_1_72_0/lib/libboost_coroutine.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::coroutine_context(void (*)(boost::context::detail::transfer_t), boost::coroutines::detail::preallocated const&)':
coroutine_context.cpp:(.text+0x59): undefined reference to `make_fcontext'
.../boost_1_72_0/lib/libboost_coroutine.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, void*)':
coroutine_context.cpp:(.text+0xe8): undefined reference to `jump_fcontext'
collect2: error: ld returned 1 exit status
make[5]: *** [Bin/RELEASE/icinga2] Error 1
```
Signed-off-by: Sven Nierlein <sven@nierlein.de>
