[CMake] Why FindBoost messaging not unified?

[Philip Lowman]

On Fri, Oct 9, 2009 at 6:05 AM, Fabio Fracassi <fabio.fracassi at charite.de>wrote:

> Philip Lowman schrieb:
>
>> If you have any other CMake related suggestions please feel free to
>> accompany your mailing list posts with a feature request and/or patch on the
>> bugtracker if you have the time.
>>
>>
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log<
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log
>> >
>>
>>  I have always wondered why FindBoost doesn't add some speculative future
> Versions into _Boost_KNOWN_VERSIONS so that at least the Boost versions that
> are likely to appear during the lifecycle of the current CMake version are
> found without resorting to user supplied Boost_ADDITIONAL_VERSIONS. There is
> no harm in searching for versions that are never going to be released
> (except maybe longer search time), is there?
>
> I was thinking of something along the lines of the attached patch.
> Or is this a horrible idea?
>

The whole Boost_ADDITIONAL_VERSIONS thing is a kludge and I think a better
solution is needed which is why I have refrained from kludging it even more
by guessing at future version numbers.  I'm not sure if this was the
original approach of the writers of FindBoost or if they had something else
in mind, however.

There's nothing preventing you from doing this yourself using
Boost_ADDITIONAL_VERSIONS though. You might even be able to come up with a
way to do it using the MATH() command and a for-loop.  I'm not sure how many
versions you would have to add before noticing a slowdown.  Probably quite a
bit.

What's really needed is find_path/find_library/etc. searches with versioned
filename support.  This could solve problems in many find modules where
libraries (or directories in the case of Boost) contain version numbers.  At
one point I was working on a patch for this and would like to get back to it
one day when I have more time (unless someone else feels like tackling the
problem sooner).

http://public.kitware.com/Bug/view.php?id=8396

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091009/c145747a/attachment.htm>