[CMake] FindBoost.cmake updated on the bugtracker

[Matthew Woehlke]

Andreas Pakulat wrote:
> 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.

...unless the system version isn't too old, but I'm trying to force a 
newer version to be used anyway :-). While there is nothing wrong with 
yelling at people to fix their broken build systems, we still at the 
least need for the system version to be thrown out if it is too old. 
Arranging for the BOOST_ROOT version to be preferred regardless solves 
(or perhaps, "avoids") this problem, and further has the advantage that 
it's easier to force a non-system version to be pulled in (and can be 
used to get past broken build systems).

Plus that's the patch I have now, and I am lazy ;-).

>>>> 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.

I didn't find it either :-(.

> 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.

...except if I found something in NO_DEFAULT_PATHS, I don't care about 
the next find. In fact, I'd wrap it in "if(NOT Boost_INCLUDE_DIR)" :-).

-- 
Matthew
 > pinotree uses the large trout on tsdgeos and PutHuhn :)
 > PutHuhn runs
 > tsdgeos lights a fire and eats the trout
(with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came 
up with this entirely on their own)