[CMake] Boost Library Search

[Philip Lowman]

On Wed, Oct 6, 2010 at 7:55 PM, assume_R <assurem at gmail.com> wrote:

> Hey all.  So I noticed a possible bug with the way boost is searched in
> findboost.cmake.
>
> Essentially, if you have the boost static runtimes installed, that's what
> Visual Studio will require.  For example, using the thread library, it will
> need libboost_thread*-sgd*
>
> Yet the non-static-runtime versions are what are searched first, so it only
> finds libboost_thread*-gd*, and visual studio will give you a link error.
>

Yes, this is issue #11204.  FindBoost searches for static libraries first
with the -gd & then -sgd prefix in that order when Boost_USE_STATIC_LIBS is
enabled.  There was no way to specify if you preferred the static library
built against a dynamic runtime, or the static library built against a
static runtime.
http://www.cmake.org/Bug/view.php?id=11204

Changing the behavior the way you specified could potentially break people
that prefer the static boost libraries but with a dynamic runtime, so a
better solution was needed.  The new version of FindBoost (which is in
2.8.3-rc2) allows you to set a new option (Boost_USE_STATIC_RUNTIME) which
allows picking either a static or dynamic runtime.  By default FindBoost
maintains existing behavior of searching for dynamic then static on WIN32
(since that is the only platform we had this behavior before).  On other
platforms this wasn't an issue and the dynamic runtime was always used so
the existing behavior is maintained there since the user must opt-in to
setting Boost_USE_STATIC_RUNTIME.

If you try out FindBoost in 2.8.3-rc2 you'll see a reference to
Boost_COMPAT_STATIC_RUNTIME which disables the double search behavior if set
to OFF.  You can set this to OFF for now, but I realized the variable is
redundant so if there are more RC's for CMake 2.8.3, I plan on removing it
and just counting on if the user has defined Boost_USE_STATIC_RUNTIME or not
(regardless if they set it ON or OFF) to disable the "double" search on
WIN32.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101006/21b5fde9/attachment.htm>