Update CMakeLists.txt to handle NEW Boost find_package

[heitbaum]

Fixes:

CMake Warning (dev) at CMakeLists.txt:317 (find_package):
  Policy CMP0167 is not set: The FindBoost module is removed.  Run "cmake
  --help-policy CMP0167" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

As the minimum boost version is 1.74 which is greater than 1.70 when Boost added the cmake module, this policy should be used.

==

CMP0167

.. versionadded:: 3.30

The FindBoost module is removed.

CMake 3.29 and below provide a FindBoost module, but it needs constant updates to keep up with upstream Boost releases. Upstream Boost 1.70 and above provide a BoostConfig.cmake package configuration file. find_package(Boost CONFIG) finds the upstream package directly, without the find module.

CMake 3.30 and above prefer to not provide the FindBoost module so that find_package(Boost) calls, without the CONFIG or NO_MODULE options, find the upstream BoostConfig.cmake directly. This policy provides compatibility for projects that have not been ported to use the upstream Boost package.

The OLD behavior of this policy is for find_package(Boost) to load CMake's FindBoost module. The NEW behavior is for find_package(Boost) to search for the upstream BoostConfig.cmake.

This policy was introduced in CMake version 3.30.
It may be set by cmake_policy() or cmake_minimum_required(). If it is not set, CMake warns, and uses OLD behavior.

.. note::
The OLD behavior of a policy is
deprecated by definition
and may be removed in a future version of CMake.

---

Pull Request Checklist

• Contributions must be licensed under the GPL-3.0 License

• This project loosely follows the Google C++ Style Guide

• For better compatibility with embedded toolchains, the used C++ standard should be limited to C++17

• Code should be formatted by running make reformat

• Branch from the develop branch and ensure it is up to date with the current develop branch before submitting your pull request. If it doesn't merge cleanly with develop, you may be asked to resolve the conflicts. Pull requests to master will be closed.

• Commits should be as small as possible while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).

• Pull requests must not contain compiled sources (already set by the default .gitignore) or binary files

• Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade version from 0.42 to 0.42.23.”).

• Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.

• If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review by contacting us via email.

• Post review:

  • If a review requires you to change your commit(s), please test the changes again.
  • Amend the affected commit(s) and force push onto your branch.
  • Set respective comments in your GitHub review to resolved.
  • Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.