[CMake] FindBoost (once again...)

[Philip Lowman]

On Sun, Nov 23, 2008 at 1:08 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 23.11.08 18:58:57, Christian Ehrlicher wrote:
> > Andreas Pakulat schrieb:
> >> On 23.11.08 14:43:19, Christian Ehrlicher wrote:
> >>> Hi,
> >>>
> >>> FindBoost does not work for me on windows because of a wrong pathname:
> >>>
> >>>       if (WIN32 AND NOT CYGWIN)
> >>>         set(_boost_PATH_SUFFIX boost_${_boost_VER})
> >>>       else (WIN32 AND NOT CYGWIN)
> >>>         set(_boost_PATH_SUFFIX boost-${_boost_VER})
> >>>       endif (WIN32 AND NOT CYGWIN)
> >>>
> >>> I installed boost with bjam and a directory
> >>> <prefix>/include/boost-1_37/  is created. Therefore the above
> >>> assumption that it's boost_1_37 is wrong.
> >>
> >> I suspect that the author used a binary boost package, but IIRC it
> wasn't
> >> me, so don't really know.
> >>
> > But why should the binary packages use another include dir? Strange... :(
>
> That was just a wild guess, because I know people did test FindBoost.cmake
> quite a bit on win32 before cmake 2.6.0 was released.
>
> >>> Also the latest cvs binary for win32 still does not have support for
> >>> boost 1.37.
> >>
> >> Thats not a problem, see the top of FindBoost.cmake, you can set
> >> Boost_ADDITIONAL_VERSIONS prior to find_package to use newer boost
> >> packages.
> >>
> > Good idea but the sources are not mine.
>
> Well, thats something that you should use when calling find_package(Boost)
> and know that boost 1.37 is supported. Unfortunately its the only easy way
> to support future versions, because Boost includes the version in library
> names and include dirs.


Would it be a good idea for FIND_LIBRARY to support some kind of numerical
wildcard matching in it's searches?  Encoding numbers in library filenames
on Windows isn't unheard of and Boost_ADDITIONAL_VERSIONS kinda sucks (I
realize there are no better alternatives without encoding every possible
future version number of Boost into FindBoost.cmake).

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