FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)

[Andreas Pakulat]

On 18.01.09 23:33:21, Andreas Pakulat wrote:
> 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.

PS: Re-Reading my post I guess it didn't come across that, I don't object
adding some globbing to find version.hpp. I was just trying to point out
the possible problems that come with that approach.

Andreas

-- 
Don't tell any big lies today.  Small ones can be just as effective.