On Jan 20, 2008 2:17 PM, Andreas Pakulat wrote: > On 20.01.08 14:02:32, Miguel A. Figueroa-Villanueva wrote: > > I guess there has been some difficulties with the boost version > > number. My suggestion would be to use a directory that includes the > > version number and extract it from there (e.g., boost_include_dir - > > .../include/boost-X.YY). Then you could just have a find_path that > > looks for that dir, having a list of version numbers like: > > We already do that, except that we simply require only listing the > version number in the variable if 1.33 to 1.34.1 is not enough. Also > I've never seen a boost installation that uses boost-z.xx.y, only z_xx_y > and the latter is definetly what boost itself uses.
Oh, I just quickly browsed through the FindBoost and thought that in linux it was 1.33 rather than 1_33... in that case you can remove half the directories... > The real problem is actually building up the "right" library names and > allowing the user to choose between > static/shared,thread/non-thread,debug/release builds. Yes, this is a problem, but how are you handling it right now? I'm thinking about the GUI user... Say your find module finds the default version when the GUI is run. How does the user change the options in the GUI when he sees that the found libs are not the ones he wants? I don't see any CMake OPTIONS that let him change the Boost_USE_NONMULTITHREAD to TRUE or the Boost_ADDITIONAL_VERSIONS variable so that when he clicks on configure again he gets the new found libs. As it is right now, I think the user would have to change each and every lib manually to get what he wants... Am I missing something? If not, then I think you should have OPTIONS (similar to http://svn.boost.org/trac/boost/wiki/CMakeBuildFeatures), say BOOST_USE_STATIC, BOOST_USE_MULTITHREADED, etc. with reasonable defaults so that the command line user can just run cmake and find what he needs by default, but that the GUI user can select what he needs after being presented by the available options. Again, I'm quite busy now, but later on I can help setting this up if you think it is a sound approach. Just my 2 cents. --Miguel _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
