[CMake] FindBoost.cmake from 2.6

[Fernando Cacciola]

Hi Andreas,

> On 03.07.08 12:23:11, Doug Gregor wrote:
>> On Tue, Jul 1, 2008 at 1:24 PM, Fernando Cacciola
>> <fernando.cacciola at gmail.com> wrote:
>>> (7)
>>>
>>> I couldn't understand the dicotomy between the cached and non-cached
>>> versions of the include dirs:
>>>
>>> Boost_INCLUDE_DIRS vs Boost_INCLUDE_DIR
>>>
>>> What's the choice for? What doesn't the library dir, or for that matter, 
>>> the
>>> libraries list offer the same choice?
>>
>> I actually don't know why this is the why it is, sorry.
>
> I'll try to read the rest later and answer everything, but for now just
> this: The module needs to be fully backwards compatible to the CMake 2.4
> version (thats why it was included in 2.6.0), and in cmake 2.4 you had
> only 2 variables, one for include dirs one for library dirs and did
> something like
>
> link_directories( ${Boost_LIBRARY_DIRS} )
> target_link_libraries( foo boost-thread )
>
Hmm, this explains why there is a cached Boost_INCLUDE_DIRS and a 
memory-onlu Boost_INCLUDE_DIR?
If so I don't get it.. can you elaborate?

> Andreas
>
>>> (9)
>>> It is documented that this requires CMake 2.5 (which is 2.6 for us end
>>> users). And later overdocumented that this ships with CMake 2.6 so the
>>> version is always right.
>>>
>>> Well, strictly speaking one can use *this* module with earlier cmake
>>> versions, such as 2.4.7 which is still largely used in many linuxes, by
>>> emulating the additional find_package feautres.
>>> That is, instead of calling it like:
>>>
>>> find_package(Boost 1.37.1 COMPONENTS thread )
>>>
>>> call it like this:
>>>
>>> set( Boost_FIND_VERSION 1.37.1 )
>>> set( Boost_FIND_VERSION_MAJOR 1 )
>>> set( Boost_FIND_VERSION_MINOR 37 )
>>> set( Boost_FIND_VERSION_PATCH 1 )
>>> set( Boost_FIND_COMPONENTS thread )
>>>
>>> find_package(Boost)
>>>
>>> which works just the same with the old find_package (this is in fact 
>>> what
>>> I'm doing in CGAL to avoid requiring users to install CMake 2.6 which is
>>> usually not just a simple apt-get/rmp call in many linuxes)
>>
>> I'm not quite sure what to do about this... with the FindBoost we ship
>> in CMake 2.6.1, we should take advantage of CMake's features (e.g.,
>> the new HINTS feature, which eliminates a bunch of redundant code).
>
> The reason its so backwards compatible is that I wanted to be
> kdevplatform's (kde module) copy to be as similar as possible (and that
> one needs to work with cmake 2.4) so that later when KDE depends on
> CMake 2.6 I'll have to do as little porting of our find-boost-code as
> possible.
>
In fact, I've tested it with 2.4.7, 2.4.8 and 2.6 amd it just worked (with 
the versioning detail I explained in my response to Doug)

Best

Fernando