find_package(Boost) support

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

find_package(Boost) support

Boost - Dev mailing list
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)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: find_package(Boost) support

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: find_package(Boost) support

Boost - Dev mailing list
Roger Leigh wrote:
> 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

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: find_package(Boost) support

Boost - Dev mailing list

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: find_package(Boost) support

Boost - Dev mailing list

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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment