On Feb 1, 2019, at 8:13 AM, Peter Dimov via Boost
wrote: The complaint about not setting Boost_LIBRARIES is correct, and I don't think we should be setting it in 2019. I understand that FindBoost can't remove it for compatibility reasons, but new code should not be propagating "old CMake" practices. Partial +1 for that. I agree but the problem is: An existing (CMake) code base may use `Boost_LIBRARIES`. The user using the code base now upgrades its Boost and CMake and now the project he is just using fails to configure. So be aware that this is a breaking change affecting existing code. I'd
provide both of possible and encourage (not force) users to use the targets.
Regarding static/shared, the config files link to whatever is specified with Boost_USE_STATIC_LIBS (ON/OFF); when not set, they link to shared when BUILD_SHARED_LIBS is ON, to static otherwise.
The alternative behavior under consideration was to always prefer shared unless Boost_USE_STATIC_LIBS=ON. Some people prefer the one, some the other, and I have no real way to gauge which one is better or more useful, with so little feedback. It would be better to only add this logic when building both static and shared together. If the users just builds static or just build shared it should only use what was built regardless of BUILD_SHARED_LIBS. Some middle ground:
- If Boost_USE_STATIC_LIBS is set to OFF or ON then use shared/static libs respectively. - Else if static&shared boost was build depend on BUILD_SHARED_LIBS - else use whatever boost was built as Main point is taking into consideration if Boost_USE_STATIC_LIBS was set at all! The current problem with FindBoost is that you could set this variable but still get the wrong libs as it set only a preference. (Limitation on CMake side especially on Windows)