boostorg / boost_install

boost_install

This repository contains the implementation of the boost-install rule. This rule, when called from a library Jamfile, creates an install target that installs the library and its CMake configuration file. It also invokes the install targets of its dependencies.

boost_install's Issues

boost_install license

Hi,
We build boost offline and with newer boost versions, the submodules are not all available, so we need to have the packages for the submodules as well, but we have strict license rules and can't use unlicensed packages.
Could you add LICENSE.txt file similar to https://github.com/boostorg/build?

Thank you.

Boost_COMPILER should accept a list

... similarly to FindBoost (since 3.9).

(As pointed out in #62.)

BoostConfig: Many target-dependent generator expressions evaluate to empty or wrong values.

This is a copy of the Gitlab Kitware Issue 20611, which applies to both FindBoost and BoostConfig

Maybe you want to deal with it differently?!:

Background

I am linking to the shared variant of Boost::log and would like to copy the shared (.dll / .so) and import (.lib, .dll.a / .a) library files to the output folder using target dependent generator expressions in an post-build command like so:

# Add a post-build command to copy all shared and import libraries
add_custom_command(TARGET ${TARGET_NAME} POST_BUILD
	# Command to copy the shared library.
	COMMAND "${CMAKE_COMMAND}" -E copy_if_different "$<TARGET_FILE:${ITERATED_COMPONENT}>" "${LIBRARY_OUTPUT_DIRECTORY}"
	# Command to copy the import library.
	COMMAND "${CMAKE_COMMAND}" -E copy_if_different "$<TARGET_LINKER_FILE:${ITERATED_COMPONENT}>" "${ARCHIVE_OUTPUT_DIRECTORY}" )

Problem

Many of the properties listed in target dependent generator expressions evaluate to empty or wrong (as far as my understanding goes) values. This is the case for both FindBoost and BoostConfig, i.e. no matter if setting Boost_NO_BOOST_CMAKE=ON or Boost_NO_BOOST_CMAKE=OFF.

Here is a list of some of the values the generator expressions evaluate to:

TARGET_NAME_IF_EXISTS: Boost::log
TARGET_FILE: <BOOST_ROOT>/lib/shared/libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_FILE_BASE_NAME: Boost::log
TARGET_FILE_PREFIX: 
TARGET_FILE_SUFFIX: 
TARGET_FILE_NAME: libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_FILE_DIR: <BOOST_ROOT>/lib/shared
TARGET_LINKER_FILE: <BOOST_ROOT>/lib/shared/libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_LINKER_FILE_BASE_NAME: Boost::log
TARGET_LINKER_FILE_PREFIX: 
TARGET_LINKER_FILE_SUFFIX: 
TARGET_LINKER_FILE_NAME: libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_LINKER_FILE_DIR: <BOOST_ROOT>/lib/shared

and what I would have expected:

TARGET_NAME_IF_EXISTS: Boost::log
TARGET_FILE: <BOOST_ROOT>/lib/shared/libboost_log-mgw93-mt-d-x64-1_72.dll
TARGET_FILE_BASE_NAME: boost_log-mgw93-mt-d-x64-1_72
TARGET_FILE_PREFIX: lib
TARGET_FILE_SUFFIX: .dll
TARGET_FILE_NAME: libboost_log-mgw93-mt-d-x64-1_72.dll
TARGET_FILE_DIR: <BOOST_ROOT>/lib/shared
TARGET_LINKER_FILE: <BOOST_ROOT>/lib/shared/libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_LINKER_FILE_BASE_NAME: boost_log-mgw93-mt-d-x64-1_72
TARGET_LINKER_FILE_PREFIX: lib
TARGET_LINKER_FILE_SUFFIX: .dll.a
TARGET_LINKER_FILE_NAME: libboost_log-mgw93-mt-d-x64-1_72.dll.a
TARGET_LINKER_FILE_DIR: <BOOST_ROOT>/lib/shared

That way I could easily copy the files.

Also the limited availability of string-manipulation generator expressions as already discussed prevents me from quickly replacing the CMAKE_IMPORT_LIBRARY_SUFFIX with the CMAKE_SHARED_LIBRARY_SUFFIX.

Workaround

I thought of a solution, which is not very pretty, but it works:

foreach(CONFIG_TYPE Debug Release)
	get_target_property(LIBRARY_FULL_PATH_${CONFIG_TYPE} Boost::log "LOCATION_${CONFIG_TYPE}")
	get_filename_component(LIBRARY_DIRECTORY_${CONFIG_TYPE} ${LIBRARY_FULL_PATH_${CONFIG_TYPE}} "DIRECTORY")
	get_filename_component(LIBRARY_NAME_${CONFIG_TYPE} ${LIBRARY_FULL_PATH_${CONFIG_TYPE}} "NAME_WE")						
endforeach() 

# Add a post-build command to copy all shared and import libraries
add_custom_command(TARGET ${TARGET_NAME} POST_BUILD
	# Command to copy the shared library.
	COMMAND "${CMAKE_COMMAND}" -E copy_if_different "$<IF:$<CONFIG:Debug>,${LIBRARY_DIRECTORY_Debug}/${LIBRARY_NAME_Debug},${LIBRARY_DIRECTORY_Release}/${LIBRARY_NAME_Release}>${CMAKE_SHARED_LIBRARY_SUFFIX}" "${LIBRARY_OUTPUT_DIRECTORY}"
	# Command to copy the import library.
	COMMAND "${CMAKE_COMMAND}" -E copy_if_different "$<IF:$<CONFIG:Debug>,${LIBRARY_DIRECTORY_Debug}/${LIBRARY_NAME_Debug},${LIBRARY_DIRECTORY_Release}/${LIBRARY_NAME_Release}>${CMAKE_IMPORT_LIBRARY_SUFFIX}" "${ARCHIVE_OUTPUT_DIRECTORY}" )

There is no such things as ${LIBRARY_DIRECTORY_$<CONFIG>}, right? I get this error:

Invalid character ('<') in a variable name

Is there a way to go around this? I tried this without success:

set(LIBRARY_NAME_GENEX LIBRARY_NAME_$<CONFIG>)	
...
COMMAND "${CMAKE_COMMAND}" -E echo $<GENEX_EVAL:${LIBRARY_NAME_GENEX}> # 'LIBRARY_NAME_Debug'
COMMAND "${CMAKE_COMMAND}" -E echo $<GENEX_EVAL:${${LIBRARY_NAME_GENEX}}> # '' (empty string)
...

boost_python suffix issues

Somewhat related to #21, but Boost 1.71 was just released into the repo for Ubuntu Focal LTS, and the story for boost_python is not great. From the perspective of an LTS user, over the years there have been five ways of linking to boost_python from CMake for a given Python X.Y:

1. find_package(Boost COMPONENTS python)
2. find_package(Boost COMPONENTS python-pyXY)
3. find_package(Boost COMPONENTS pythonX)
4. find_package(Boost COMPONENTS pythonX-pyXY)
5. find_package(Boost COMPONENTS pythonXY)

Xenial's Boost (1.58) supported 1 and 2. Bionic's Boost (1.65.1) supported 1, 2, 3, and 4. Focal's Boost (currently 1.71) supports only 1 and 5. But using 1 on Focal gets you Python 3 whereas previously 1 got you Python 2. There is no one invocation that consistently gets you the Python 3 bindings.

My appeal is for Boost to continue supporting the python3 and numpy3 component names, at least long enough for any software that wants to support multiple LTS releases from a single branch. Particularly when you consider that Boost_VERSION has now been changed so that it is no longer usable for checks against systems old enough to not yet have Boost_VERSION_MACRO (for example, Ubuntu Bionic, where FindBoost is supplied by CMake 1.10).

Launchpad ticket for the same issue: https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209

BoostConfig.cmake does not honor QUIET argument

Dear Boost team,

When integrating a Boost 1.70.0 installation in our CMake based projects, we get spammed like this:

-- Found Boost 1.70.0 at /home/dklein/boost_1_70_0_install/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS system;program_options;container
-- Found boost_headers 1.70.0 at /home/dklein/boost_1_70_0_install/lib/cmake/boost_headers-1.70.0
-- Found boost_system 1.70.0 at /home/dklein/boost_1_70_0_install/lib/cmake/boost_system-1.70.0
--   libboost_system.a
-- Adding boost_system dependencies: headers
-- Found boost_program_options 1.70.0 at /home/dklein/boost_1_70_0_install/lib/cmake/boost_program_options-1.70.0
--   libboost_program_options.a
-- Adding boost_program_options dependencies: headers
-- Found boost_container 1.70.0 at /home/dklein/boost_1_70_0_install/lib/cmake/boost_container-1.70.0
--   libboost_container.a
-- Adding boost_container dependencies: headers
-- Boost 1.70.0 found.
-- Found Boost components:
   system;program_options;container

even though we passed QUIET to the find_package command as the output confirms.

Looking at the information printed, it reminds on the output of the standard handler CMake provides for FindModule authors, see find_package_handle_standard_args(). If you really need to print the above information, I recommend (with decending order of importance)

1. to only print anything, if QUIET is not passed,
2. only print information once, reprint only, if something has changed (this is also the behaviour of the above mentioned package), and
3. streamline the user experience by following the output formatting chosen in the above mentioned package (Even the upstream FindBoost.cmake shipped with CMake delivers a messy user experience, because it insists in printing status lines in its own custom format which makes CMake output hard to read in the context of many dependencies that all insist on their own style...)

(Instead of printing anything at all in any case, I would prefer if you just export properly documented CMake variables that contain all of such useful infos and enable the user of your package to decide, if anything needs to be printed or evaluated in any other manner. At least it would be nice, if a complete and reasonably detailed variable export of useful infos would get a prioritized attention opposed to the printed human-readable output.)

Thank you.

CMake always inspects BUILD_SHARED_LIBS

Currently, since boost 1.70.0, imported CMake targets for boost libraries inspect the BUILD_SHARED_LIBS variable and complain if its boost setting does not match the project's setting (and e.g. suggest to add an additional CMake variable Boost_USE_STATIC_LIBS=OFF in case BUILD_SHARED_LIBS is not ON).

While the idea is nice and makes sense in some cases when building libraries, checks for BUILD_SHARED_LIBS only makes sense for CMake projects build libraries. They do not make sense for other projects that, for example, only build executables via ADD_EXECUTABLE().

Hence, CMake projects for executables currently always need to be configured with an additional non-project-related variable Boost_USE_STATIC_LIBS such that FIND_PACKAGE(Boost) does not fail.

Actually, I think it would be cleaner to skip the check on BUILD_SHARED_LIBS completely and leave it to the developer to ensure that he configures boost and derived projects consistently.

Install .dll files into bin directory

Hello,

On Windows, .dll files are installed in the lib/ directory under the prefix. This is quite awkward and should be installed into bin/ directory as many other projects and conventions do.

Thus, user that adds PATH to a common prefix + bin/ will have runtime dependencies correctly.

Boost_LIBRARIES not defined

 # It's roughly, but not perfectly, compatible with the behavior
 # of find_package(Boost) as provided by FindBoost.cmake.

Having read that, in practice, it's not really compatible with the current software out there. This makes it not very useful for distributions like openSUSE Tumbleweed or related for now. The main problem is that Boost_LIBRARIES is not set. So even after finding all the libraries, software just doesn't link against Boost.

And since this package is basically overriding the cmake's version of FindBoost, the only solution is not to ship Boost's version for now. For example,

https://build.opensuse.org/package/show/home:adamm:boost_test/ledger

fails with link errors because Boost_LIBRARIES is undefined. This package basically just uses these setting,

find_package(Boost 1.49.0
  REQUIRED date_time filesystem system iostreams regex unit_test_framework
  ${BOOST_PYTHON})

include_directories(SYSTEM ${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})

set(CMAKE_REQUIRED_INCLUDES ${CMAKE_INCLUDE_PATH} ${Boost_INCLUDE_DIRS})
set(CMAKE_REQUIRED_LIBRARIES ${Boost_LIBRARIES} icuuc ${PROFILE_LIBS})

Variant files shouldn't be installed when there's no lib-target

In the generate-cmake-variant rule, when $(lib-target) is empty, we still generate a variant.cmake file, which is undesirable.

I've tried to fix that in 4c2bc82, but this results in b2 warnings of the form

warning: Unable to construct libs/stacktrace/build/boost_stacktrace_backtrace-variant.cmake

(happens because boost_stacktrace_backtrace is disabled with check-target-builds.)

@swatanabe, do you have any ideas how these messages can be avoided? Perhaps I need to return some kind of a dummy target from the rule?

Can't seem to use Boost_COMPILER with windows build

My Use case: I have built boost with VS2017 (vc141 toolset) and I would like to link to it in a VS2019 project (vc142 toolset). I thought setting Boost_COMPILER to "vc141" would allow this, but I always seem to hit the second case here in the config files:

if(Boost_COMPILER AND NOT Boost_COMPILER STREQUAL "vc141")
  _BOOST_SKIPPED("libboost_chrono-vc141-mt-gd-x64-1_70.lib" "vc141, Boost_COMPILER=${Boost_COMPILER}")
  return()
endif()

if(BOOST_DETECTED_TOOLSET AND NOT BOOST_DETECTED_TOOLSET STREQUAL "vc141")
  _BOOST_SKIPPED("libboost_chrono-vc141-mt-gd-x64-1_70.lib" "vc141, detected ${BOOST_DETECTED_TOOLSET}, set Boost_COMPILER to override")
  return()
endif()

...that is, since BOOST_DETECTED_TOOLSET is always set to the auto-detected value (vc142 in my case), it hits the second return here and can't proceed to find the vc141 libs that do exist.

Am I doing something wrong or is it possible that the BOOST_DETECTED_TOOLSET block above shouldn't be in the generated configs perhaps?

Are CMake files supposed to bring in dependencies?

Consider this CMakeLists.txt file:

project(Boost CXX)
cmake_minimum_required(VERSION 3.0)

FIND_PACKAGE(Boost COMPONENTS thread REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})

ADD_EXECUTABLE(test test.cpp)
TARGET_LINK_LIBRARIES(test ${Boost_LIBRARIES})

with this test.cpp file:

#include <boost/thread/condition_variable.hpp>

int main() {
    boost::condition_variable cv;
    boost::mutex mutex;
    boost::unique_lock<boost::mutex> lock(mutex);
    cv.wait_for(lock, boost::chrono::seconds(1));
    return 0;
}

When I try to compile with cmake . and make, the compilation fails with

[100%] Linking CXX executable test
/usr/bin/ld: CMakeFiles/test.dir/test.cpp.o: in function `boost::cv_status boost::condition_variable::wait_for<long, boost::ratio<1l, 1l> >(boost::unique_lock<boost::mutex>&, boost::chrono::duration<long, boost::ratio<1l, 1l> > const&)':
test.cpp:(.text._ZN5boost18condition_variable8wait_forIlNS_5ratioILl1ELl1EEEEENS_9cv_statusERNS_11unique_lockINS_5mutexEEERKNS_6chrono8durationIT_T0_EE[_ZN5boost18condition_variable8wait_forIlNS_5ratioILl1ELl1EEEEENS_9cv_statusERNS_11unique_lockINS_5mutexEEERKNS_6chrono8durationIT_T0_EE]+0x15): undefined reference to `boost::chrono::steady_clock::now()'
collect2: error: ld returned 1 exit status

Clearly boost::condition_variable::wait_from requires boost::chrono::steady_clock::now, but the latter is not automatically brought in as a dependency by CMake scripts. Should I expect CMake to automatically resolve dependencies towards other Boost libraries (i.e., this is a bug), or am I supposed to explicitly specify chrono in the CMakeLists.txt file?

Thanks.

DESTDIR support

The environment variable DESTDIR needs to be respected (on POSIX platforms.) See discussion in #14.

cmake: INTERFACE_COMPILE_DEFINITIONS are overwritten in the variant configuration files

There is a conflict between the common config file and the variants. The INTERFACE_COMPILE_DEFINITIONS set in:

boost_install/boost-install.jam

Lines 623 to 625 in 8ca34ab

	"set_target_properties($(ltarget) PROPERTIES"
	" INTERFACE_INCLUDE_DIRECTORIES \"\${_BOOST_INCLUDEDIR}\""
	" INTERFACE_COMPILE_DEFINITIONS \"BOOST_ALL_NO_LIB\""

are overwritten in the variant files in:

boost_install/boost-install.jam

Lines 368 to 370 in 8ca34ab

	"set_target_properties($(target) PROPERTIES"
	" INTERFACE_COMPILE_DEFINITIONS \"BOOST_$(lname:U)_DYN_LINK\""
	" )"

This does not show up as a bug because most targets depend on Boost::headers and they will get BOOST_ALL_NO_LIB transitively from it. On the other hand some libraries do not depend on Boost::headers (I could see Boost::math an Boost::exception).

I am not sure if the intention was to extend or overwrite but it sounds more logical to me to provide common properties in the common config file and specialize (extend) in the variant files. In any case I noticed this when I was patching the common file and the extra settings did not appear in the final build.

I will start a PR with a fix.

Boost_USE_STATIC_RUNTIME when not set should be autodetected from CMAKE_MSVC_RUNTIME_LIBRARY

C.f. https://gitlab.kitware.com/cmake/cmake/-/issues/22214

Why is "BOOST_ALL_NO_LIB" set automatically?

Hi,

I found out that inboost_headers-config.cmake the Target Boost::headers sets BOOST_ALL_NO_LIB:

set_target_properties(Boost::headers PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_BOOST_INCLUDEDIR}"
  INTERFACE_COMPILE_DEFINITIONS "BOOST_ALL_NO_LIB"
)

Why is it disabled and how can I enable it?

What's the purpose of the Targets Boost::disable_autolinking and Boost::dynamic_linking if Boost by default already disabled autolinking?

Also, I believe this is a difference in regard to https://cmake.org/cmake/help/latest/module/FindBoost.html which afaik doesn't disable it by default.

Boost configs broken by cross-prefix symlinks

On Arch /lib64 and /usr/lib64 are symlinks to /usr/lib, so a Boost installed into /usr but found via /lib64 will fail to set the correct paths for e.g. the include dir as reported in https://gitlab.kitware.com/cmake/cmake/issues/19841 (It will try to use /include instead of /usr/include where the former does not exist)

A solution would look similar to https://gitlab.kitware.com/cmake/cmake/blob/v3.15.4/Source/cmExportInstallFileGenerator.cxx#L201-219 as mentioned by Brad King at https://gitlab.kitware.com/cmake/cmake/issues/19841#note_640123

Meta-component "ALL" is printing superfluous warnings about missing Boost components

I just tested the current Boost 1.73.0 beta1 version and came across the following inconvenience:

When using the new meta-component ALL (as in find_package( Boost 1.73.0 REQUIRED ALL CONFIG )) I get warnings about some Boost components for which the package configuration file is available and can be found but which says that the associated Boost component/library is not available (which is correct).

I was building Boost on Linux and the following Boost components are not available although their package-configuration files are created (and installed) when building:

• boost_fiber_numa
• boost_graph_parallel
• boost_numpy
• boost_stacktrace_windbg
• boost_stacktrace_windbg

I do not know if the associated package-configuration files (e.g. boost_fiber_numa-config.cmake) should not have been installed in the first place or if the find_package call should have been silent about them missing.

Whether these package-configuration files should be generated and installed or not, I realized that the internal find_package can only be silenced if the entire find_package( Boost ... ALL ... ) call has the QUIET option.

Is that how it is supposed to be?

It should not be too hard to patch BoostConfig.cmake to always search quietly for individual components when using the meta-component ALL. (I could provide a pull-request for it if desired.)

BoostConfig.cmake should define version numbers etc.

When looking at https://cmake.org/cmake/help/latest/module/FindBoost.html, the BoostConfig.cmake version should also define

Boost_VERSION - BOOST_VERSION value from boost/version.hpp
Boost_LIB_VERSION - Version string appended to library filenames
Boost_MAJOR_VERSION - Boost major version number (X in X.y.z)
Boost_MINOR_VERSION - Boost minor version number (Y in x.Y.z)
Boost_SUBMINOR_VERSION - Boost subminor version number (Z in x.y.Z)
Boost_VERSION_STRING - Boost version number in x.y.z format

Other variables like Boost_C_FOUND etc. might not be necessary anymore with imported targets since this can be done with IF(TARGET Boost::C) - but for backward compatibility they would not hurt (otherwise, all CMake projects using Boost need to be modified for after version 1.70)

Boost_COMPILER content not compatible with CMake FindBoost

CMake expects the content of the variable Boost_COMPILER to start with a dash (e.g. "-vc142"), but the CMake scripts generated by a Boost build expect them without the dash (e.g. "vc142"), which are not passed through by CMake. This causes matching libraries to be rejected. A workaround is not to use those scripts by setting Boost_NO_BOOST_CMAKE to ON.

Tested on Windows 10 with Visual Studio 2019, CMake 3.14.4 and Boost 1.70.0.

Versioned symlinks are now installed, but used to not be

As reported on the mailing list: https://lists.boost.org/Archives/boost/2020/06/249155.php

CMake package of libraries with dependencies to external libraries

Some Boost libraries have dependencies to third party libraries: Boost.Iostreams (zlib, bzip2), Boost.Local (ICU), Boost.MPI (some MPI lib) come to mind.

In the current configuration package generated by the boost-install rule, the dependency to the third party library is not set explicitly. If we look at the Iostreams test:

add_executable(test_gzip test_gzip.cpp)
target_link_libraries(test_gzip Boost::iostreams)
target_link_libraries(test_gzip ZLIB::ZLIB) # should not be necessary

This introduce subtle issues with the linking order since the dependency graph is

test_gzip  <-- Boost::iostreams
           <-- ZLIB::ZLIB

instead of

test_gzip  <-- Boost::iostreams <-- ZLIB::ZLIB

A possible solution would be to add something like find_dependency(ZLIB) and target_link_libraries(Boost::iostreams ZLIB::ZLIB) in the CMake config file.

Building without a library seems to install its headers

I'm trying to partially build Boost 1.75.0 by passing using b2's --without-<library> option:

  --without-<library>     Do not build, stage, or install the specified
                          <library>. By default, all libraries are built.

For example for the log library:

./b2 --without-log

The configuration reports gives:

    - log                      : not building

This prevent the libboost_log from being built and installed (which is indeed expected) but it the log headers at include/boost/log/ still get installed by ./b2 install... Is that expected or am I missing something here?

Exclusion of static libs for static runtime usage

If I do a build with default settings (e.g. just ./b2 install) on linux, I get dynamic and static libs built using the system naming convention. By default, boost assumes a shared runtime. For static libs, however, does it really matter? For instance, my consuming application specifies both Boost_USE_STATIC_LIBS and Boost_USE_STATIC_RUNTIME and thus the default install fails to find the library because of this cmake config code (just using chrono as an example here) :

# runtime-link=shared

if(Boost_USE_STATIC_RUNTIME)
    _BOOST_SKIPPED("libboost_chrono.a" "shared runtime, Boost_USE_STATIC_RUNTIME=${Boost_USE_STATIC_RUNTIME}")
    return()
endif()

When I switch to a tagged layout and build versions for both static and shared runtime, I get two copies of what appear to be the same static library. Couldn't we just make an exception and allow the system layout to work for either runtime choice? I realize this might be OS dependent since windows is clearly different in this regard and apple-clang doesn't allow static runtime at all (I believe).

Exported CMake config should use thirdparty lib targets and preferably find them on its own

if(CMAKE_CONFIGURATION_TYPES)
  set_property(TARGET Boost::iostreams APPEND PROPERTY INTERFACE_LINK_LIBRARIES
    "$<$<CONFIG:release>:bz2;lzma;z;zstd>")
else()
  set_property(TARGET Boost::iostreams APPEND PROPERTY INTERFACE_LINK_LIBRARIES
    bz2 lzma z zstd)
endif()

This is not going to work if I just link to Boost::iostreams. How should a consumer know that those libraries are needed?
If I am not mistaken, In modern CMake you would call find_dependencies(ZSTD::ZSTD $Version) and then link to the imported target in your exported CMake file.

This gets especially tricky with boost::regex and ICU, where I don't even know which version I should find in my own CMake script that is "finding" boost.

Support for Boost_USE_MULTITHREADED missing

See https://gitlab.kitware.com/cmake/cmake/issues/19714.

I have not verified if one can legally end up in this state or if the user has installed non-mt and mt variants into the same existing prefix.

• If it is legal, we would need support for Boost_USE_MULTITHREADED,
• if it is illegal, we should probably replace the variant globbing with an explicit list or clean the cmake package directories before installing.

cmake configs don't allow static vs shared library paths

The cmake configs don't allow static vs shared library paths...

For example, from tools/boost_install/boost-install.jam

/boot/system/lib/cmake/boost_wave-1.70.0/boost_wave-config.cmake:get_filename_component(_BOOST_LIBDIR "${_BOOST_CMAKEDIR}/../" ABSOLUTE)

That sets _BOOST_LIBDIR to the cmake dir ../ (aka /usr/lib/cmake/../ for libraries)

Then all libraries are put into it...

/boot/system/lib/cmake/boost_unit_test_framework-1.70.0/libboost_unit_test_framework-variant-static.cmake:  IMPORTED_LOCATION_RELEASE "${_BOOST_LIBDIR}/libboost_unit_test_framework.a"
/boot/system/lib/cmake/boost_unit_test_framework-1.70.0/libboost_unit_test_framework-variant-shared.cmake:  IMPORTED_LOCATION_RELEASE "${_BOOST_LIBDIR}/libboost_unit_test_framework.so.1.70.0"

This is not the case on all operating systems. It's a common design to have the static libraries in a different prefix path.
Example:

• /boot/system/lib/libboost_unit_test_framework.so
• /boot/system/develop/lib/libboost_unit_test_framework.a

It looks like a _BOOST_STATIC_LIBDIR or something is needed?

[Question] Is it possible to set the correct library type (STATIC/SHARED) when requesting a specific one?

Hi,

I am very new to the Config mode of the FindBoost module but I found that the library type of the created imported targets is (in all my builds so far) set to UNKNOWN (I suppose here: https://github.com/boostorg/boost_install/blob/develop/boost-install.jam#L915).

Would it be possible to set this to the actual type so that our library and its target_link_library calls have this information? From what I understood it is important for target_link_library to know if a dependency is STATIC or SHARED since its logic depends on it.

I think the old FindBoost.cmake way actually (at least for the specific request of Static libraries) sets this property correctly: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L2218

I understand that, especially for the FindBoost.cmake way, doing this correctly is not always easy (e.g. on Win where both types basically end with ".lib").

But I am curious to know if this would be possible with the config approach. Or maybe it is possible and I am doing something wrong?

Non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries

Recently boost 1.75.0 was added to homebrew-core in Homebrew/homebrew-core#66792, after which I started noticing some failures in some of my software that links against boost (osrf/homebrew-simulation#1235) with linking errors like ld: library not found for -licudata. I believe part of the reason is that all non-Boost dependencies were added to the cmake INTERFACE_LINK_LIBRARIES in 0e39586, but this should not be necessary for libraries that use target_link_libraries with the PRIVATE keyword, such as boost_regex (the source of the problem in my case).

Is it possible to exclude PRIVATEly linked libraries from INTERFACE_LINK_LIBRARIES?

IntelLLVM is not supported

Intel C/C++ compilers switched to LLVM and new ICX compiler is reported with CMAKE_CXX_COMPILER_ID set to IntelLLVM by CMake (testing CMake 3.23.1). This new string seems not to be handled correctly by BoostDetectToolset.cmake and throws messages like:

-- Boost toolset is unknown (compiler IntelLLVM 2022.1.0)

BoostDetectToolset.cmake doesn't match version number generated with b2

When I build my libraries on MingW using GCC 9.2, I get library names as follows:

libboost_serialization-mgw92-mt-x64-1_73.a

But, when I try to consume Boost from cmake using something like:

find_package( Boost CONFIG REQUIRED serialization)

I get an error like:

Found package configuration file:
[cmake] 
[cmake]     C:/Users/cdglo/src/cmn/boost/stage/lib/cmake/boost_serialization-1.73.0/boost_serialization-config.cmake
[cmake] 
[cmake]   but it set boost_serialization_FOUND to FALSE so package
[cmake]   "boost_serialization" is considered to be NOT FOUND.  Reason given by
[cmake]   package:
[cmake] 
[cmake]   No suitable build variant has been found.
[cmake] 
[cmake]   The following variants have been tried and rejected:
[cmake] 
[cmake] 
[cmake]   * libboost_serialization-mgw92-mt-d-x64-1_73.a (mgw92, detected mgw9, set
[cmake]   Boost_COMPILER to override)
[cmake] 
[cmake]   * libboost_serialization-mgw92-mt-x64-1_73.a (mgw92, detected mgw9, set
[cmake]   Boost_COMPILER to override)
[cmake] 
[cmake]   * libboost_serialization-vc142-mt-gd-x64-1_73.lib (vc142, detected mgw9,
[cmake]   set Boost_COMPILER to override)
[cmake] 
[cmake]   * libboost_serialization-vc142-mt-x64-1_73.lib (vc142, detected mgw9, set
[cmake]   Boost_COMPILER to override)
[cmake] 
[cmake] Call Stack (most recent call first):
[cmake]   C:/Users/cdglo/src/cmn/boost/stage/lib/cmake/Boost/BoostConfig.cmake:185 (boost_find_component)
[cmake]   CMakeLists.txt:23 (find_package)
[cmake] 

The error being here:

mgw92, detected mgw9

I found that removing this code from BoostDetectToolset fixes this issue for me, but I'm not sure sure why that code is there.

elseif(MINGW)

  set(BOOST_DETECTED_TOOLSET "mgw")

  # if(_BOOST_COMPILER_VERSION_MAJOR GREATER 4)
  #  set(_BOOST_COMPILER_VERSION_MINOR)**
  # endif()

`b2 install python=2.7 python=3.3` fails

... with

error: Name clash for '<pc:\boost-prefix\lib\cmake\boost_python-1.71.0>libboost_python-variant-shared.cmake'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error:     -  <python>2.7
error:     -  <python>3.3
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.

See boostorg/python#262.

Component dependencies

Similar to #18, but more tractable since it is internal dependencies only.

find_package(Boost CONFIG COMPONENTS thread)

ends up with an "unknown target Boost::system" message. The transitive closure of the requested components should be made available to the requesting package because otherwise every package needs to embed this information internally. FindBoost.cmake handled the dependency tree at least, so this behavior for compatibility across the gap would be really helpful in that way too.

error in BoostDetectToolset

when using cmake find_package, the output is:
-- Boost toolset is mgw8 (GNU 8.1.0)
-- Including D:/Boost/lib/cmake/boost_system-1.70.0/libboost_system-variant-mgw81-mt-d-x64-1_70-static.cmake
-- ... skipped libboost_system-mgw81-mt-d-x64-1_70.a (mgw81, detected mgw8, set Boost_COMPILER to override)
CMake Error at D:/Boost/lib/cmake/Boost-1.70.0/BoostConfig.cmake:95 (find_package):
Found package configuration file:

D:/Boost/lib/cmake/boost_system-1.70.0/boost_system-config.cmake

I found:

elseif(MINGW)

set(BOOST_DETECTED_TOOLSET "mgw")

if(_BOOST_COMPILER_VERSION_MAJOR GREATER 4)
set(_BOOST_COMPILER_VERSION_MINOR)
endif()

in BoostDetectToolset-1.70.0.cmake ，this led to errors.

CMake configuration file missing dependency to MPI::MPI_C

The CMake configuration files generated at installation with boostorg/boost_install have an imported target that is missing a dependency to the underlying MPI library. The symptoms are an invalid linking order and the associated undefined symbols errors.

@pdimov, what would be the right way to have something like find_dependency(MPI) and target_link_libraries(Boost::mpi PUBLIC MPI::MPI_C) added to the config file? Shall we add a test for MPI to the boost_install test suite?

Boost 1.70's cmake config makes cmake stop looking where I tell it to

Boost 1.70's cmake config makes cmake stop looking where I tell it to in two ways:

1. With Boost 1.68, I could tell cmake the location of the Boost I wanted to use with either a BOOST_ROOT environment variable or a -DBOOST_ROOT=[...] command line flag but with 1.70.0, the latter option has stopped working.
2. If I have a Boost 1.70 directory in /opt/, cmake uses that one instead of the Boost (either 1.68 or 1.70) in another location that I explicitly request (via either a BOOST_ROOT environment variable or a -DBOOST_ROOT=[...] command line flag). Even if I have two Boost 1.70 directories in /opt/, cmake chooses which one to use itself, disregarding my explicit choice.

I have seen these issues with cmake-3.12.1-Linux-x86_64 and cmake-3.15.0-rc3-Linux-x86_64.

Apologies: I'm not sure whether this issue should be raised here or against FindBoost.cmake on https://gitlab.kitware.com/cmake — I'm guessing here because the problem appears to be associated with a change in the Boost version not the CMake version. Sorry if that's incorrect.

boost_1_72_0-msvc-14.2-64 _BOOST_INCLUDEDIR problem with find_package(CONFIG)

hi
I am trying to use the latest boost release with CMake find_package(CONFIG), but the boost cmake config seems to incorrectly define the interface include directories that are then applied for my executable that links to boost.

Boost is installed (by default) in C:\local\boost_1_72_0 on windows.
The boost cmake config that resolves the header include directories is in:
C:\local\boost_1_72_0\lib64-msvc-14.2\cmake\boost_headers-1.72.0\boost_headers-config.cmake
The problem is that at the end of the config _BOOST_INCLUDEDIR points to C:\local when it should actually point to C:\local\boost_1_72_0.

If in boost_headers-config.cmake I change the line:
get_filename_component(_BOOST_INCLUDEDIR "${_BOOST_CMAKEDIR}/../../../" ABSOLUTE)
to:
get_filename_component(_BOOST_INCLUDEDIR "${_BOOST_CMAKEDIR}/../../" ABSOLUTE)
... then I can compile my project without problems.
With the original line above I can see that the incorrect include directory is set in Visual Studio and hence I get errors that the boost includes can not be found.

PS: I am not sure if I am using the find_package() syntax correctly with regard to boost, especially how to declare the path that find_package() should use to look for boost configs, so please correct me if I am doing something wrong on that end. Thanks

A minimal reproduction of what I'm doing looks like this:

CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
project(cmake-boost-test)

# set(Boost_DEBUG TRUE)
# set(Boost_USE_STATIC_LIBS OFF)

find_package(Boost 1.72.0 EXACT COMPONENTS date_time REQUIRED CONFIG PATHS "C:/local/boost_1_72_0/lib64-msvc-14.2/cmake")

add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PUBLIC
    Boost::date_time
)

main.cpp

#include <iostream>
#include <boost/date_time.hpp>

using namespace boost::gregorian;

int main(int argc, char** argv)
{
    std::cout << "hello world!" << std::endl;

    // test boost::date_time
    std::string s("2001-10-9"); //2001-October-09
    date d(from_simple_string(s));
    std::cout << to_simple_string(d) << std::endl;

    return 0;
}

boost_mpi tries to find the C++ MPI API

boost_mpi is only based on the C MPI API. Yet the the generated cmake code tries to import the C++ API, bringing in more stuff than necessary. Along with the associated problems:

CMake Error in /ccc/work/cont003/gen7233/miniussa/views/fargo/fargOCA/icc/rel/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Imported target "MPI::MPI_CXX" includes non-existent path

Inconsistent boost cmake file names

I'm not quite sure what is going on, and I'm not sure if this is a bug in mpi module or the cmake generation. Currently 1.71 build emits:

boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi-1.71.0/libboost_mpi-variant-static.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi-1.71.0/boost_mpi-config-version.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi-1.71.0/boost_mpi-config.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi-1.71.0/libboost_mpi-variant-shared.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/mpi-config.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/mpi-config-version.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/libmpi-variant-shared-py3.8.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/libmpi-variant-shared-py3.7.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/libmpi-variant-static-py3.7.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/mpi-1.71.0/libmpi-variant-static-py3.8.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/boost_mpi_python-config-version.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/libboost_mpi_python-variant-static-py3.8.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/libboost_mpi_python-variant-shared-py3.8.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/libboost_mpi_python-variant-static-py3.7.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/libboost_mpi_python-variant-shared-py3.7.cmake exists in debian/tmp but is not installed to anywhere
boost1.71_1.71.0-1_amd64.build:dh_missing: usr/lib/x86_64-linux-gnu/cmake/boost_mpi_python-1.71.0/boost_mpi_python-config.cmake exists in debian/tmp but is not installed to anywhere

And I can understand boost_mpi-1.71.0/ and the boost_mpi_python-1.71.0 but i am very confused about the mpi-1.71.0/ as to what it is, and which library I should package it with: boost_mpi or boost_mpi_python or if it shouldn't exist at all!

Is it like cmake files generated for the compiled python mpi extension? ie. the one that is installed on Debian systems as:

-rw-r--r-- root/root       264 2019-03-12 03:44 ./usr/lib/python3/dist-packages/boost/__init__.py
-rw-r--r-- root/root    497112 2019-03-12 03:44 ./usr/lib/python3/dist-packages/boost/mpi.cpython-37m-x86_64-linux-gnu.so
-rw-r--r-- root/root    501208 2019-03-12 03:44 ./usr/lib/python3/dist-packages/boost/mpi.cpython-38-x86_64-linux-gnu.so

Frankly, I don't understand cmake files for boost here =)

bzip2 upgrade

Can bzip2 please be upgraded to 1.0.8 in order to mitigate CVE-2019-12900?

Allow CMake's `find_package` to find all components without knowing their name.

Problem:

Currently, if one uses CMake's find_package command to look for a BoostConfig.cmake file, one has to list all (desired) components (aka Boost libraries with binaries) explicitly, like this:

find_package( Boost 1.71.0 REQUIRED
              COMPONENTS unit_test_framework filesystem program_options ...  # all compiled boost libs
              CONFIG)

This is tedious, particularly if one wants to find all Boost libraries, to make all targets available to one's CMake project (and sub-projects thereof).
With every new Boost version one needs to check and possibly update that listing to incorporate new libraries.

Suggested Feature:

It would be very helpful if a single component, let's call it all, would exist which makes find_package automatically search for all Boost libraries (may they be binary or header-only) belonging to the desired version.

As a result, imported targets for all Boost components as well as the header-only targets (at least Boost::headers and Boost::boost) and maybe some other useful imported targets should be created.

Additionally, a special variable, let's call it Boost_ALL_TARGETS, should be set which contains the names of all these imported targets.
This would allow to comfortably promote all these targets to global scope, using the following command:

set_target_properties( ${Boost_ALL_TARGETS}
                       PROPERTIES IMPORTED_GLOBAL TRUE )

At the end, one could do the following in any (sub-)project of one's CMake project and make all of Boost available to all other projects without needing to know at this point what Boost libraries are contained in the requested version.

find_package( Boost ${ANY_BOOST_VERSION} REQUIRED
              COMPONENTS all
              CONFIG
)
if ( Boost_FOUND )
    set_target_properties( ${Boost_ALL_TARGETS}
                           PROPERTIES IMPORTED_GLOBAL TRUE )
endif ()

PDB files should be installed along with DLLs

This is now done when staging in 49c63cd, but installing uses package.install, and it doesn't install PDBs.

staging-prefix not respected by cmake files

If I install Boost with b2 install --prefix=/usr staging-prefix=/tmp/stage/usr the libraries are installed to /tmp/stage/usr/lib/... but fails as the the cmake files are not relocated under the staging prefix:

common.mkdir /usr/lib/cmake
| mkdir: cannot create directory ‘/usr/lib/cmake’: Permission denied

[CMake] Target for component is added even if the correct variant of a component is NOT found.

Using Boost 1.72, when trying to find a component using find_package(Boost ...) a target for the component is added even though the correct component may not have been found, e.g. only the debug variant has been found, but the release variant is needed.

Taking Boost::log for example. In the file cmake\boost_log-1.72.0\boost_log-config.cmake generated by Boost.Build (b2), the target is added 'very early' in line 31. The check for the correct variant starts in line 66.
Calling find_package(Boost ...) a second time is useless, because of lines 3 to 5:

if(TARGET Boost::log)
  return()
endif()

The if(TARGET ...) always returns true since it was already added in the previous call in line 31.

That prevents a mechanism of searching for a component, building the correct variant if the wrong one was found, and finding the correct variant on the second call.

I propose to call the code add_library(Boost::log UNKNOWN IMPORTED) only if a suitable build variant has been found since there is no way to remove the useless target by calling something like remove_library(Boost::log).

Some CMake files for Python and NumPy lack version suffix

Downstream may need Python 2 and Python 3 to coexist on an installed system. However, doing so would override the following files:

lib/cmake/boost_numpy-1.72.0/boost_numpy-config-version.cmake
lib/cmake/boost_numpy-1.72.0/boost_numpy-config.cmake
lib/cmake/boost_python-1.72.0/boost_python-config-version.cmake
lib/cmake/boost_python-1.72.0/boost_python-config.cmake

Boost.Stacktrace libraries are not being installed by `b2 install`

Running the following command line:

bjam -j 8 --prefix="$HOME/boost_install_root" toolset=gcc variant=release threading=multi debug-symbols=on runtime-link=shared numa=on link=static,shared --with-stacktrace install

does not result in Boost.Stacktrace libraries installed in $HOME/boost_install_root. The library is being successfully built, and its libraries are present in $BOOST_ROOT/bin.v2, but the only thing that is installed is CMake config files - no headers, no libraries.

This is a regression in 1.78, 1.77 worked fine. Boost.Stacktrace hasn't changed in this regard between releases, so my current suspects are Boost.Install or Boost.Build.

This is on Kubuntu 21.10.

Note that for other libraries, like Boost.Atomic for example, the above command works as intended.

CMake - Cannot link both debug AND release libraries

As far as I know, it is currently not possible to add both the debug and the release libraries to a target using the cmake code generated by Boost.Build (b2) during the built process. This is a problem for multi-configuration generators like MS VS2019 or Xcode, as well as e.g. the CMAKE_BUILD_TYPE RelWithDebInfo.

For single-configuration generators and a CMAKE_BUILD_TYPE Debug or Release it is easy to add boost.
I first define both variables Boost_USE_DEBUG_LIBS and Boost_USE_RELEASE_LIBS, then search for the boost components I want to add, e.g. Boost::log, and link the found targets.

# Define Boost_USE_DEBUG_LIBS and Boost_USE_RELEASE_LIBS 
# Check if a multi-config generator is used.
if(GENERATOR_IS_MULTI_CONFIG)
	# A multi-configuration generator is used. Use debug and release libs.
	set(Boost_USE_DEBUG_LIBS ON)  
	set(Boost_USE_RELEASE_LIBS ON)
else()
	# If not, check which kind of configuration is beeing built.
	if(${CMAKE_BUILD_TYPE} STREQUAL "Debug" )
		# Only debug libraries are needed.
		set(Boost_USE_DEBUG_LIBS ON)  
		set(Boost_USE_RELEASE_LIBS OFF)  
	elseif(${CMAKE_BUILD_TYPE} STREQUAL  "RelWithDebInfo")
		# Both debug and release libraries are needed.
		set(Boost_USE_DEBUG_LIBS ON)  
		set(Boost_USE_RELEASE_LIBS ON)
	else()
		# Only release libraries are needed.
		set(Boost_USE_DEBUG_LIBS OFF)  
		set(Boost_USE_RELEASE_LIBS ON)
	endif()
endif()

# Find Boost
find_package(Boost 1.72
				REQUIRED 
				COMPONENTS log
				PATHS ${BOOST_HOME}/cmake)

# Automagically add the component to the target, adding the 'include' folder and static or shared and import library.
target_link_libraries(${TARGET_NAME} PRIVATE Boost::log)

If both Boost_USE_DEBUG_LIBS and Boost_USE_RELEASE_LIBS is set to ON only the debug libraries are found! Because of that it is not possible to add both debug and release libraries to the target!

In my eyes the files created by Boost.Build (b2) and copied into the install folder (e.g. ${BOOST_HOME}/cmake) should make the method find_package(Boost ...) create variables like for example so: Boost::Release::log, Boost::Debug::log.
Maybe even including the compiler, target architecture and bitness for cross-compilation, like so: Boost::<CONFIG>::<COMPILER_TAG>::<TARGET_ARCH>::<COMPONENT>, e.g. Boost::Release::mgw93::x86::log?!

That way one could link the appropiate libraries like so:

target_link_libraries(${TARGET_NAME} PRIVATE 
					debug Boost::Debug::mgw93::x86::log 
					optimized Boost::Release::mgw93::x86::log)

BoostDetectToolset.cmake needs to be updated to support detection of vc143 toolset with MSVC 2022

When calling BoostDetectToolset.cmake using MSVC 2022 compilers, BOOST_DETECTED_TOOLSET contains an empty string.

to fix: around line 92 in BoostDetectToolset.cmake: please add a couple lines as shown below:

if((MSVC_VERSION GREATER 1929) AND (MSVC_VERSION LESS 1940))
    set(BOOST_DETECTED_TOOLSET "vc143")
elseif((MSVC_VERSION GREATER 1919) AND (MSVC_VERSION LESS 1930))
    set(BOOST_DETECTED_TOOLSET "vc142")
else ...

Some CMake options are not marked as advanced

When building a CMake project which depends on Boost and one uses find_package(Boost CONFIG) to find the installed Boost libraries, the CMake cache variables for Boost which are listed in cmake-gui are mostly marked as advanced (using the mark_as_advanced CMake command), however, not all of them are.

These CMake cache variables have the form boost_<library-name>_DIR and point to the directories which contains the CMake config scripts for importing the associated Boost library.
However, these variables exist for all such installed config scripts, even if the associated library is not provided for the build platform (and therefore not installed).
Examples for such variables on a Linux platform are:

• boost_fiber_numa_DIR
• boost_numpy_DIR
• boost_stacktrace_windbg_DIR
• boost_stracktrace_windbg_cached_DIR

In that case these variables are not marked as advanced and are therefore always shown, even if cmake-gui shall only display non-advanced options.

I recommend, these variables should still be marked as advanced.

boost's cmake config files are not compatible with clang-cl

On Windows, clang-cl is compatible for compiling and linking against MSVC libraries.
In this case with MSVC compiled boost. Therefore, the cmake-config file should not report "NOTFOUND" if I actually want MSVC compiled boost libraries to be linked. Boost should also generally detect if clang is running in compatibility mode for msvc and simulate a build as with msvc as well.

Include version matching for mpi_python

The FindBoost module states

Note that Boost Python components require a Python version suffix
(Boost 1.67 and later), e.g. python36 or python27 for the
versions built against Python 3.6 and 2.7, respectively. This also
applies to additional components using Python including
mpi_python and numpy.

However in BoostConfig only "^python" is checked which means this fails for mpi_python. Is that intentional?