[CMake] FindBoost.cmake from 2.6

[Fernando Cacciola]

Andreas Pakulat wrote:
> On 03.07.08 19:40:29, Fernando Cacciola wrote:
>>> 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?
>
> Well, check out the README file in the Modules directory. It tells you
> that Boost_INCLUDE_DIRS shouldn't be cached but it doesn't say anything
> about Boost_INCLUDE_DIR. So thats what the module does right now. It
> uses Boost_INCLUDE_DIR when searching for the headers (which caches the
> value) but sets INCLUDE_DIRS on every run to the cached value if it
> exists.
>
Ha OK.
My next question would be why shouldn't the Boost_INCLUDE_DIRS be cached, 
but I'll ask that on a separate thread.

Fernando