# Boost\_LIBRARIES differs for module mode vs config mode.
**URL:** https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792
**Category:** Code
**Created:** [May 3, 2024, 9:09am UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792 "2024-05-03T09:09:05Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jwuttke](https://discourse.cmake.org/u/jwuttke)
#### Post date: [May 3, 2024, 9:09am UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792/1 "2024-05-03T09:09:05Z")
`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?
[1] [boost\_install/BoostConfig.cmake at boost-1.85.0 · boostorg/boost\_install · GitHub](https://github.com/boostorg/boost_install/blob/boost-1.85.0/BoostConfig.cmake)
[2] [https://gitlab.kitware.com/cmake/cmake/-/issues/23406](https://gitlab.kitware.com/cmake/cmake/-/issues/23406)
[3] [https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/9487](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9487)
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 3, 2024, 1:28pm UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792/2 "2024-05-03T13:28:11Z")
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?
---
### Author:  [@jwuttke](https://discourse.cmake.org/u/jwuttke)
#### Post date: [May 3, 2024, 1:46pm UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792/3 "2024-05-03T13:46:00Z")
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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 3, 2024, 2:26pm UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792/4 "2024-05-03T14:26:18Z")
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.
---
### Author:  [@jwuttke](https://discourse.cmake.org/u/jwuttke)
#### Post date: [May 3, 2024, 5:33pm UTC](https://discourse.cmake.org/t/boost-libraries-differs-for-module-mode-vs-config-mode/10792/5 "2024-05-03T17:33:19Z")
Not straightforward. Function `_boost_set_legacy_variables_from_config` depends on other functions and macros. If I copy all these, and call
```auto
find_package_handle_standard_args(Boost HANDLE_COMPONENTS CONFIG_MODE)
_boost_set_legacy_variables_from_config()
```
then `Boost_LIBRARIES` still contains targets, not paths.