Update `mpi_python##` and `numpy##` component dependencies to honor
python version suffixes on components named by the caller. Although
upstream Boost did not add version suffixes prior to version 1.67, it is
commonly done by distros. Honor suffixes specified by project code.
Projects must take responsibility for naming distro-specific component
suffixes for versions prior to 1.67.
Fixes: #17892, #17970
Per discussion on cmake/cmake#17575, this protection not particularly
valuable, as the dependency information which the imported targets wrap
is generated anyway.
This removes a road-block for using `Boost_ADDITIONAL_VERSIONS` to
support newly-released Boost versions pending a new CMake release.
Release notes: http://www.boost.org/users/history/version_1_66_0.html
* All new libraries are header-only.
* _Boost_COMPONENT_DEPENDENCIES is unchanged from 1.65.1
* _Boost_FIBER_COMPILER_FEATURES is unchanged from 1.64.0
Add a test for this case to verify the messages. This test will also be
valuable to cover this code path in which we've had several regressions
recently.
Instead of `list(FIND...)` and then checking result for `-1`
(found/not-found), nowadays `if` command has the `IN_LIST` test for
that.
This change was originally made by commit v3.9.0-rc1~41^2 (FindBoost:
Simplify search in lists, 2017-04-23) but then had to be reverted by
commit v3.9.2~3^2 (FindBoost: Revert "Simplify search in lists.",
2017-09-05) due to problems related to using `find_dependency`. Those
problems were addressed by commit 3080a0a611 (FindBoost: Improve
behavior when thread dependency is missing, 2017-09-15), so now we can
restore the original change.
Issue: #17252
The `find_dependency` macro is not meant for use in find modules and
`return()`s from the caller when the package is not found. Avoid using
it in FindBoost. Instead use plain `find_package` for the Threads
package and manually forward the `QUIET` argument. When the Threads
package is missing then treat the Boost `thread` component as missing.
Issue: #17257
With the use of options `Boost_USE_DEBUG_LIBS` and
`Boost_USE_RELEASE_LIBS` it is now possible to skip searching for either
DEBUG or RELEASE Boost libraries.
This is useful if Boost is installed on the system in multiple
directories but only one of them should be used which only contains e.g.
the RELEASE libraries. Without this change the DEBUG libraries might be
found in the other directory which might not be desired at all.
Revert commit v3.9.0-rc1~41^2 (FindBoost: Simplify search in lists,
2017-04-23). It regressed the module by exposing issue #17257, but the
fix for that issue is not suitable for inclusion in a patch release.
It is simplest to revert the commit until the larger problem can be
addressed.
Fixes: #17252
Some boost libraries may require particular set of compler features.
The very first one was `boost::fiber` introduced in Boost 1.62.
One can check required compiler features of it in
`${Boost_ROOT}/libs/fiber/build/Jamfile.v2`.
Since commit v3.8.0-rc1~136^2 (FindBoost: Search official location of
prebuilt binaries on Windows, 2016-12-21) we pass input paths through
`_Boost_UPDATE_WINDOWS_LIBRARY_SEARCH_DIRS_WITH_PREBUILT_PATHS` in more
places than before. This broke tolerance of backslashes in paths
provided by the user due to the macro argument re-parsing. Turn
`_Boost_UPDATE_WINDOWS_LIBRARY_SEARCH_DIRS_WITH_PREBUILT_PATHS` into a
function instead of macro to avoid re-parsing of macro arguments.
Fixes: #16816
Changes in commit 3ca6f70f (FindBoost: Allow testing for multiple
compiler suffixes, 2017-03-28) accidentally left a `set()` instead of a
`list(APPEND)` while constructing `_boost_RELEASE_NAMES`. Fix the logic
to match what was done for `_boost_DEBUG_NAMES`. Otherwise we drop some
of the candidate names.
Update the module to enable finding components of Boost 1.64 (beta) from
the upcoming release. Also update the Boost library name mangling used
for VS 2017 to match a change made to Boost upstream (vc150 => vc1410).
This fixes a regression introduced by commit v3.3.0-rc1~5^2~2
(FindBoost: Search for debug and release libraries separately,
2015-01-26). The `_Boost_CHANGE_LIBDIR` variable was split into
`_Boost_CHANGE_LIBDIR_{DEBUG,RELEASE}` but one usage site was not
updated.
Make it possible to find Boost in the default install path (`c:\boost`)
of an official prebuilt binaries installation even when `BOOST_ROOT`
has not been specified.