On Sun, Jan 18, 2009 at 11:33 PM, Andreas Pakulat <[email protected]> wrote:
>> >> 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... If you sort the result of FILE( GLOB ... ) so that the most recent version comes first (i. e. 1.37.0 in this case), globbing would not be any different from having a list of versions in FindBoost.cmake. >> > 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). I'd say readability or understandability stopped being a problem in FindBoost.cmake a long time ago ;-) >> > 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. Given that CMake is being added as a new build system for Boost, my hopes are this would create and install some kind of UseBoost-<version>.cmake. >> > 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. The problem we face now is we do not even arrive that far in the "checklist": 1. Write application 2. Find Boost <- Here is were we fail now 3. Build my application with the found Boost version <- Here is where we would fail if we parse version.hpp -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
