FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
Andreas Pakulat
apaku at gmx.de
Sun Jan 18 23:33:21 CET 2009
On 18.01.09 12:50:32, Pau Garcia i Quiles wrote:
> On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
> >> On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter <winter at kde.org> wrote:
> >> > On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
> >> >> Hello,
> >> >>
> >> >> FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
> >> >> not support Boost 1.37.0. You need to replace this line:
> >> >>
> >> >> SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} "1.36.1"
> >> >> "1.36.0" "1.35.1" "1.35.0" "1.35" "1.34.1" "1.34.0" "1.34" "1.33.1"
> >> >> "1.33.0" "1.33" )
> >> >>
> >> >> with
> >> >>
> >> >> SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} "1.37.0"
> >> >> "1.36.1" "1.36.0" "1.35.1" "1.35.0" "1.35" "1.34.1" "1.34.0" "1.34"
> >> >> "1.33.1" "1.33.0" "1.33" )
> >> >>
> >> > This is quite silly.
> >>
> >> I fully agree but that's the way FindBoost.cmake is implemented in
> >> CMake and several places in the KDE repository.
> >>
> >> Parsing boost/version.hpp seems like the right way to do version
> >> detection. From Boost 1.35.0 :
> >
> > But how do you find that _easily_? Boost installs its headers into
> > <prefix>/include/boost-<version>/boost/, so we need the version to try to find
> > boost. The only way to avoid that is writing platform specific cmake code
> > that iterates for <includedir>/boost-* and checks in each one for a
> > boost/version.hpp.
>
> FILE(GLOB ... ) and FILE( GLOB_RECURSE )... to the rescue! Using the
> globbing expressions "boost", "boost-*" and "Boost-*" would be
> probably enough. Furthermore, you usually only have one version of
> Boost installed, two or three tops, so FILE( GLOB/GLOB_RECURSE ...)
> should not take long.
The OP had 5 versions installed actually and in his case its even more
complicated, because with globbing you might find boost 1.34 and use that
(as the project works with that). That might or might not be ok for the
user...
> > This would be quite a bit more code, as <includedir> is
> > different on each of the 3 major platforms.
>
> FindBoost.cmake is already long enough (638 lines in CMake 2.6.2), so
> a hundred more lines are not a problem, IMHO.
I'd say that this wouldn't increase readability or "understandability" of
the module, but as only few people touch it thats probably true (i.e. not a
real problem).
> > IMNSHO we should either get Boost people to stop this insanity
>
> Good luck with that! On the other hand, this "insanity" allows for
> different Boost versions to be co-installed.
There are far better ways to do that.
> > or just
> > better document that projects using FindBoost should set
> > Boost_ADDITIONAL_VERSIONS to a list of versions they know their project
> > builds with.
>
> The problem with that is when a new version is out.
Not really, if a project uses boost, one of its dev should _check_ that it
still works with the newer version (As I said in the other mail,
kdevplatform for example doesn't build with 1.37). And if he verified that,
he can simply commit the change.
IMHO you can't assume that your boost-using project will work just fine
with a newer version.
Andreas
--
There is a fly on your nose.
More information about the Kde-buildsystem
mailing list