Remove FindBoost.cmake from kdelibs

[Andreas Pakulat]

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.

Looking at the modules I've installed here all of them search for KDE4
before searching for Boost (explicitly as well as "by accident" because
the boost-call is in a subdirectory).

So, from my side this is a +1 to the plan above, except that I'm still
not sure we should push this out with 4.3...
 
> > I guess that means removing the file is not an option at the moment and
> > as its pretty close to the release I'll re-tackle this after trunk/ is
> > open for 4.4, so I don't create any problems just before releasing when
> > updating the file to the cmake 2.6.4 version.
> 
> In case, out FindBoost.cmake should be updated for Boost 1.38 and 1.39 
> (released three days ago). I can do that, whichever solution we agree about 
> (ie mine above or our FindBoost.cmake).

Hmm, I'd like to leave FindBoost.cmake alone as much as possible so its
easier to remove it (if we don't do it now). If we add 1.38/1.39 now to
our copy we'll have to either do the above at some point or wait until a
KDE release depends on a cmake version that either also has 1.38/1.39
fixed or a more generic fix to support all boost versions.

Andreas

-- 
Think twice before speaking, but don't say "think think click click".