[CMake] FindBoost.cmake updated on the bugtracker

[Andreas Pakulat]

On 02.04.08 16:47:34, Matthew Woehlke wrote:
> 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 ;-).

Ok, I give in. Do you mind separating the loop into two so its easier to
see whats going on and we don't have two use-less cache variables?  Then
I'll apply what you send to kdevplatform and add a new version to the
cmake bugreport.

Andreas

-- 
Long life is in store for you.