On Fri, Mar 19, 2010 at 10:22 AM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > /home/myuser/projects/boost-1.41.0/lib/libboost_date_time-mt.so > /home/myuser/projects/boost-1.41.0/lib/libboost_thread-mt.so > /usr/local/lib/libboost_filesystem-mt.so > /usr/local/lib/libboost_python-mt.so > > This mix and match is definitely not desired. It almost seems like if the > BOOST_ROOT variable is set then that should get used exclusively as the > search path and not just appended to the front.
I've had the same thought (and wish it had been implemented that way) but refrained from changing the behavior of this in the past, mainly because it could break some people's builds (some people may treat BOOST_ROOT as a "use it if it's there" feature or have it accidentally set while building on certain platforms where Boost is provided in the system path). Also, FindBoost would need to check the environment variables BOOST_ROOT and possibly BOOST_LIBRARYDIR and BOOST_INCLUDEDIR as well and if they are set enable this new behavior. > Thoughts? I could add a public variable to FindBoost which disables searching the system paths and call it out in the documentation. It would basically set NO_CMAKE_SYSTEM_PATH on all of the find_library() and find_path() calls. Alternatively, we could make the module behave as you describe and hope that it doesn't break too many people. What do you think? -- Philip Lowman _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
