Boost_LIBRARIES differs for module mode vs config mode.

BoostConfig.cmake [1] is meant as drop-in replacement for CMake’ FindBoost module [2,3]. Instead of find_package(Boost ...) we just use find_package(Boost CONFIG ...). However, the result variable Boost_LIBRARIES differs: Instead of, say, /usr/lib/x86_64-linux-gnu/ I now get Boost::iostreams. Instead of a full shared-library path, just a target name. How can I retrieve the former from the latter?

[1] boost_install/BoostConfig.cmake at boost-1.85.0 · boostorg/boost_install · GitHub

Working with imported targets is the modern and preferred way to use packages. Library paths don’t capture behavior in multi-config generators well, and don’t propagate usage requirements. Why do you need them?

A complex project, multi-platform, C++ with Qt-based GUI and Swig-generated Python API, packaged as binary installers and Python wheels, started 13 years ago. Wish so much all that were steered by modern CMake. In reality, we have a mixture of CMake idioms, plus shell scripts, plus Python scripts. We are working hard to gradually improve, but for the time being we still need explicit library paths. We are stlll running our own recursion to set RPATHs and to pack libs into installers.

The FindBoost module has an internal _boost_set_legacy_variables_from_config function it uses to populate Boost_LIBRARIES with the library file paths by extracting the information from the upstream’s imported targets. You could write your own code using the same approach.

Not straightforward. Function _boost_set_legacy_variables_from_config depends on other functions and macros. If I copy all these, and call

find_package_handle_standard_args(Boost HANDLE_COMPONENTS CONFIG_MODE)

then Boost_LIBRARIES still contains targets, not paths.