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/libboost_iostreams.so 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?
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.