Remove FindBoost.cmake from kdelibs

[Alexander Neundorf]

On Wednesday 06 May 2009, Andreas Pakulat wrote:
> On 06.05.09 00:15:24, Pino Toscano wrote:
> > Alle martedì 05 maggio 2009, Andreas Pakulat ha scritto:
> > > On 14.04.09 19:15:17, Alexander Neundorf wrote:
> > > > On Saturday 11 April 2009, Andreas Pakulat wrote:
> > > > > as cmake 2.6.2 and 2.6.3 ship with very good FindBoost.cmake files
> > > > > and the module has a dedicated maintainer who quickly responds to
> > > > > bugreports, how about removing the one in kdelibs? If removing is
> > > > > not an option, we should at least update it to the version thats
> > > > > being shipped with CMake 2.6.4.
> > > > >
> > > > > Thoughts?
> > > >
> > > > It's up to you, you know that module.
> > > > We require CMake >= 2.6.2, so please make sure whatever you do it
> > > > works with CMake 2.6.2.
> > > > (also if you go for updating to the version from CMake 2.6.4, check
> > > > that there's nothing in it which breaks with 2.6.2).
> > >
> > > I finally remembered and did this now. There's one problem, the version
> > > in kdelibs already has been updated to include "out of the box" support
> > > for boost 1.37 (1.37 has been added to the _boost_TEST_VERSIONS
> > > variable). While cmake 2.6.2 only has 1.36.1 in it. So all places using
> > > find_package(Boost) would need to be adjusted to set
> > > Boost_ADDITIONAL_VERSIONS before finding boost.
> >
> > What about adding in FindKDE4Internal.cmake a snippet like:
> >   set(_KDE_Boost_ADDITIONAL_VERSIONS "1.39.0" "1.39" "1.38.0" "1.38"
> >                                      "1.37.0" "1.37")
> >   set(Boost_ADDITIONAL_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
> >                                 ${_KDE_Boost_ADDITIONAL_VERSIONS})
> > this way:
> > a) there's no need to have an additional FindBoost.cmake
> > b) the internal _KDE_Boost_ADDITIONAL_VERSIONS variable will be updated
> > to contain the list of Boost versions not covered by the FindBoost.cmake
> > of the minimum cmake version we depend upon
> > c) if somebody specifies Boost_ADDITIONAL_VERSIONS on cmake command line,
> > that value will have precedence over any other, like now
> > d) we can guarantee compatibility for KDE applications (as long as
> > find_package(Boost) is called -after- find_package(KDE4), as the list of
> > Boost releases will always be the one we want (cmake ones + new ones not
> > yet covered, see b) too)
> > Does it sound reasonable or am I missing anything?
>
> Well, as you noted in d) the only problem would be apps that are finding
> boost before kde4 and happen to be built on systems that have boost 1.37
> installed. I'd like to hear Alex opinion on this, as it technically can
> break apps.

In general I'm for removing it.
But of course it must not break anything.
Putting Boost_ADDITIONAL_VERSIONS in FindKDE4Internal.cmake would (mostly) 
work, but I think it doesn't feel right to have a special setting for one of 
the many cmake modules in FindKDE4Internal.cmake.
Another option would be to put this into KDE4Defaults.cmake, which is 
optional, and contains only settings.

Or how about that ?
Instead of completely removing FindBoost.cmake, we replace it with an almost 
empty one:

set(Boost_ADDITIONAL_VERSIONS "1.39.0" "1.39" "1.38.0" "1.38"
                                      "1.37.0" "1.37")

include(${CMAKE_ROOT}/Modules/FindBoost.cmake)

This way we wouldn't have additional logic in our version, but we would still 
add these version numbers so we stay compatible.
(and it would be very local).

Alex