The current master and develop branches now install the necessary BoostConfig.cmake file (in $prefix/lib/cmake) such that f.ex. the CMake command find_package(Boost REQUIRED filesystem) will find Boost 1.70 using the config file, rather than via FindBoost.cmake (*) (if the Boost installation prefix is in CMake's prefix search path.) Interested parties are invited to test this support and share their experiences. Instead of a Git checkout, you can use the 1.70 release snapshots from https://dl.bintray.com/boostorg/master/ or https://dl.bintray.com/boostorg/develop/, as those better represent what the 1.70 release will contain. (*) Actually, the above command will invoke FindBoost.cmake, but FindBoost will look for a config file as a first step and use that, if found. To disable FindBoost completely, use find_package(Boost CONFIG REQUIRED filesystem) Or, on Windows, assuming the default C:\Boost installation, find_package(Boost REQUIRED filesystem PATHS C:/Boost)
On 12/01/2019 18:33, Peter Dimov via Boost wrote:
The current master and develop branches now install the necessary BoostConfig.cmake file (in $prefix/lib/cmake) such that f.ex. the CMake command
find_package(Boost REQUIRED filesystem)
will find Boost 1.70 using the config file, rather than via FindBoost.cmake (*) (if the Boost installation prefix is in CMake's prefix search path.)
A heads up from the CMake side. Unfortunately, this is causing breakage with FindBoost, and we got the first bug: https://gitlab.kitware.com/cmake/cmake/issues/18865 It looks like for the specific modules concerned, it's not behaving entirely compatibly with FindBoost. Would it be possible to rectify this? Since FindBoost is delegating to these new Config modules when present, it's a requirement that it behave identically to avoid any breakage. Alternatively, we could remove the delegation logic in FindBoost and do a hard break, so users will have to explicitly opt in to the Boost-provided Config files. It wouldn't be as nice, but it might be more robust; and it would also obviate the need for strict compatibility. I'd prefer this to be an option of last resort though. The main point I wanted to make is that while the transition might have some disruptions, we can't have an incomplete or broken state for 1.70, or major chaos will ensue. Kind regards, Roger
Roger Leigh wrote:
A heads up from the CMake side. Unfortunately, this is causing breakage with FindBoost, and we got the first bug:
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. 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. The FindBoost behavior - link to whatever's found - is not easy to duplicate under our scheme and I won't be pursuing it.
It looks like for the specific modules concerned, it's not behaving entirely compatibly with FindBoost. Would it be possible to rectify this?
I don't think that we can achieve exact compatibility even if we wanted to.
On Feb 1, 2019, at 8:13 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Roger Leigh wrote:
A heads up from the CMake side. Unfortunately, this is causing breakage with FindBoost, and we got the first bug:
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.
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. Paul
On Feb 1, 2019, at 8:13 AM, Peter Dimov via Boost <boost@lists.boost.org> 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)
participants (4)
-
Alexander Grund -
Paul Fultz II -
Peter Dimov -
Roger Leigh