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.
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
