[CMake] Making FindBoost prefer Boost_ROOT

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 26.03.08 19:10:16, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> Hmm, actually you're right. I guess either I was confused when I wrote
>>> the module or I just wanted everything to look the same :)
>> Search-and-replace error indeed. Thought that might be it ;-).
> 
> Actually (after checking the code again more thoroughly) that naming is
> intentional because the variable is a CMake variable. But at the same
> time its also possible to supply it as environment variable.

I think you're looking at the wrong spot :-). I'm looking at 
$ENV{Boost_ROOT}, not the cmake variable (which I see now there is also).

> However, looking at the fact that cmake itself uses all-upper-case for
> variables that can be specified on the commandline I'm going to  change
> these 3 too (there's also _INCLUDEDIR and _LIBRARYDIR)

Ok, makes sense. Actually if they are inputs, uppercase probably makes 
sense. Same-as-the-module case should of course be used for variables 
that are meant for consumption by the CMakeLists.txt that called 
findpackage(Boost), but I think _ROOT and friends are not in this category?

>>> Will change that tomorrow when I work on the FindBoost.cmake for CMake
>>> 2.6
>> Ok, thanks. (At which point I'll have conflicts; whee! But that's ok ;-).)
> 
> :) Hope it won't be too many. If you want to further push for having
> FindBoost.cmake in kdelibs I'd really appreciate it if that would be the
> one from kdevplatform as AFAIK thats the only one supporting searching
> for various boost libraries which KDevplatform needs to have.

AFAIK the one in kdevplatform is the only one in KDE's svn. I have 
others (which I now made symlinks to the kdevplatform one), because the 
one with my cmake, which those modules apparently use, is insufficient 
for me.

If that won't be a maintenance issue for kdevelop, I'll probably plan to 
do it next week if no one has objected.

-- 
Matthew
That said, if this is coming out of your posterior then you should 
consider your diet. -- Richard Moore, in response to Aaron Seigo's 
stated source of suggested enum values.