On Sun, Nov 23, 2008 at 1:08 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de" target="_blank">apaku@gmx.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On 23.11.08 18:58:57, Christian Ehrlicher wrote:<br>
> Andreas Pakulat schrieb:<br>
>> On 23.11.08 14:43:19, Christian Ehrlicher wrote:<br>
>>> Hi,<br>
>>><br>
>>> FindBoost does not work for me on windows because of a wrong pathname:<br>
>>><br>
>>> if (WIN32 AND NOT CYGWIN)<br>
>>> set(_boost_PATH_SUFFIX boost_${_boost_VER})<br>
>>> else (WIN32 AND NOT CYGWIN)<br>
>>> set(_boost_PATH_SUFFIX boost-${_boost_VER})<br>
>>> endif (WIN32 AND NOT CYGWIN)<br>
>>><br>
>>> I installed boost with bjam and a directory<br>
>>> <prefix>/include/boost-1_37/ is created. Therefore the above<br>
>>> assumption that it's boost_1_37 is wrong.<br>
>><br>
>> I suspect that the author used a binary boost package, but IIRC it wasn't<br>
>> me, so don't really know.<br>
>><br>
> But why should the binary packages use another include dir? Strange... :(<br>
<br>
</div>That was just a wild guess, because I know people did test FindBoost.cmake<br>
quite a bit on win32 before cmake 2.6.0 was released.<br>
<div><br>
>>> Also the latest cvs binary for win32 still does not have support for<br>
>>> boost 1.37.<br>
>><br>
>> Thats not a problem, see the top of FindBoost.cmake, you can set<br>
>> Boost_ADDITIONAL_VERSIONS prior to find_package to use newer boost<br>
>> packages.<br>
>><br>
> Good idea but the sources are not mine.<br>
<br>
</div>Well, thats something that you should use when calling find_package(Boost)<br>
and know that boost 1.37 is supported. Unfortunately its the only easy way<br>
to support future versions, because Boost includes the version in library<br>
names and include dirs.</blockquote><div><br>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).<br>
<br></div></div>-- <br>Philip Lowman<br>