Remove FindBoost.cmake from kdelibs

[Pino Toscano]

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?

> 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).

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090506/a3b425fd/attachment.sig