In a previous post I identified several scenarios for CMake support, where number one was 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). For this, I said "The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen." but I lied. (Well, not entirely, I had a lot of help.) Here https://github.com/pdimov/boost-cmake-demo is a proof-of-concept implementation that more or less works for our beloved test case of Boost.System. To test (the instructions are for Windows, where I tested), clone the repo, do b2 headers b2 --build-type=complete install as usual, then b2 cmake//install variant=debug,release link=static,shared runtime-link=shared (or whatever combination of options you prefer.) This should install -config.cmake files into $prefix/libs/cmake. Then, in a CMakeLists.txt, cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) #set(BOOST_BUILD_VARIANT RELEASE) #set(BOOST_LINK_TYPE SHARED) #set(BOOST_RUNTIME_LINK STATIC) find_package(boost_core 1.63.0) find_package(boost_system 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::core boost::system) or similar. Ideally, cmake//install would be integrated into the install target (and cmake//stage into stage, respectively.)