[CMake] FindBoost.cmake updated on the bugtracker

[Matthew Woehlke]

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

> 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?)

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. This also works when users don't 
set the minimum version number.

If you add a maximum version number, I think you'll need to re-add 
rejecting wrong versions *inside* the find loop. Or keep my way and 
trust the user to set BOOST_ROOT or one of the other preferred-path 
indicators appropriately.

>> 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?)

> b) it doesn't break the loop as soon as it finds a proper include dir
> (hmm, maybe thats actually needed - I'll have a closer look tomorrow,
> need some sleep now).

...which I think is only possible in CMake 2.6 (ok, a moot point for 2.6 
FindBoost, but not (yet) for KDE's copy). But I don't see why this is an 
issue; either it will keep looking because it hasn't found something yet 
(desired), or else a few useless IF's will be evaluated. I don't think 
that the latter is sufficiently costly to be a concern.

> I'm leaning towards agreement, but am not yet completely convinced that
> its absolutely necessary to go on searching for "preferred" paths even
> if the system path meets the expectations (i.e. has a version that is
> larger than the minimum required).

The alternative is to re-write the loop in two parts; search all 
suffixes in NO_DEFAULT_PATHS first, then repeat with DEFAULT_PATHS if 
nothing was found. And I'm fine with that solution as well; it achieves 
the same effect as my current code with slightly different (perhaps more 
efficient) flow. Let me know if you'd like me to re-write that way.

-- 
Matthew
Yesterday, I thought of the best .sig that has ever been contemplated. 
Alas, I forgot it before I could write it down.