Re: [boost] find_package(Boost) support

Subject: Re: [boost] find_package(Boost) support
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-02-04 09:49:07

>> On Feb 1, 2019, at 8:13 AM, Peter Dimov via Boost <boost_at_[hidden]> 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)