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 <[email protected]> wrote: > > > On 18.01.09 02:22:30, Pau Garcia i Quiles wrote: > > >> On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter <[email protected]> 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. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
