[CMake] FindBoost.cmake updated on the bugtracker

[Andreas Pakulat]

On 01.04.08 21:53:59, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
>> On 01.04.08 16:37:42, Matthew Woehlke wrote:
>>> Andreas Pakulat wrote:
>>>> On 31.03.08 20:14:00, Matthew Woehlke wrote:
>>>> Also note that those variables you use in
>>>> find_path are automatically cached and I don't think they should appear
>>>> in it.
>>>>
>>>> Apart from that, you're iterating over all test versions, thats
>>>> unecessary.
>>> Um... no. Here's what happens without the patch:
>>
>> Exactly what I suspected. So would you mind explaining why you can't use
>> the version in /usr?
>
> It's too old :-).

Then I don't quite understand what the problem is.

>> I'd just like to know wether the script might
>> actually need a minimum as well as a maximum number, because boost
>> doesn't play by the rules and breaks source/binary compatibility.
>
> Um... doesn't it already have a minimum version number? The problem is,  
> users of FindBoost don't always DTRT and set it. (I guess you meant  
> adding a maximum number?)

Thats a bug in those users CMakeLists.txt and need to be fixed there,
not trying to workaround that in the find module. Writers of buildsystem
need to define their dependencies properly.

> The previous version checked and rejected versions that didn't meet the  
> minimum version number, so in a sense you might say we've gone  
> backwards. But I think preferring BOOST_ROOT over /usr should be  
> sufficient; presumably if you set BOOST_ROOT you know what you are  
> doing, and intend for that to be used.

Thats exactly why I lean towards adopting your patch :)

> This also works when users don't  set the minimum version number.

Which hides a bug in other people's CMakeLists.txt

>>> Here's an updated patch (note that I used --ignore-all-spaces to diff 
>>> so  the indentation changes don't make it noisier than it needs to 
>>> be):
>>
>> Which still has the two problems
>>
>> a) it puts two completely useless variables into the cache
>
> There should be a way to clear them after the loop runs? (Are empty  
> variables still cached? What/where is the 'unset' command?)

I was too lazy to look into it, but as far as I can see there's no
unset command. But you can do something like

find_package(Boost_INCLUDE_DIR...)
if( Boost_INCLUDE_DIR )
  set(Boost_PREFERRED_INCLUDE_DIR ${Boost_INCLUDE_DIR})
  set(Boost_INClUDE_DIR "Boost_INCLUDE_DIR-NOTFOUND" CACHE FORCE)
endif(...)

to reset the variable so the next find is run as well.

Andreas

-- 
You will be recognized and honored as a community leader.