Hi Chuck, Whatever way you look at it, problems will likely arise sooner or later with different Boost versions. I ran into this problem because /usr/lib/libboost_date_time-mt.so was found before /home/loose/boost-1.40.0/lib/libboost_date_time.so.
My point in turning the loop inside out stems from the fact that there are dozens of FindXXX modules that may be vulnerable to the same problem. To name a few: FindGTK, FindLua50, FindPNG, FindWxWindows, etc. W.r.t. FindBoost, maybe it's wise to use BOOST_ROOT exclusively when specified. That would at least preclude the current problems. BTW: Is there a reason why I cannot specify options like NO_CMAKE_ENVIRONMENT_PATH, NO_SYSTEM_ENVIRONMENT_PATH, etc. with FIND_PACKAGE(), except when using config mode? Best regards, Marcel Loose. On Fri, 2010-03-19 at 10:22 -0400, Chuck Atkins wrote: > With multiple versions installed, setting the BOOST_ROOT variable will > force the FindBoost module to search the desired location first. > Turning the loop inside out wouldn't really solve the problem when > multiple libraries are searched for (date_time, thread). The problem > arises when multiple versions are available with different > capabilities. For example: boost installed in /usr/local has all the > libraries available but the one installed > in /home/myuser/projects/boost-1.41.0 might only have a partial subset > of the libraries available, say only date_time and thread for example. > Since the FindBoost module searches the BOOST_ROOT path in addition to > the other paths, a conflict could arise where the module finds > something like: > > /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. > > Thoughts? > > Chuck Atkins > > > On Fri, Mar 19, 2010 at 7:12 AM, Marcel Loose <lo...@astron.nl> wrote: > Hi Michael, > > That still doesn't answer my question about turning that loop > inside > out. > > A quick grep in the CMake Modules directory showed me that > there are at > least a dozen other FindXXX scripts that use multiple NAMES > with a > FIND_XXX() commands. I haven't checked how they handle default > (system) > paths, but I guess these might be erratic as well, when > multiple > versions of a package exists with libraries named slightly > different. > > Best regards, > Marcel Loose. > > > On Fri, 2010-03-19 at 06:50 -0400, Philip Lowman wrote: > > Someone could add an option to FindBoost that will simply > exclude the > > system paths from the search. This has never been implied > by setting > > BOOST_ROOT. As long as the unversioned library names are > being > > searched for with find_library they are likely going to be > found. > > Currently the onus is on the user to double check what > FindBoost > > discovers. > > > > > On Mar 19, 2010 4:56 AM, "Marcel Loose" <lo...@astron.nl> > wrote: > > > > > > Well, in my case, the library name was not even that > specific. > > > It found /usr/lib/libboost_date_time-mt.so > > > > before /home/loose/boost/boost-1.40.0/lib/libboost_date_time.so, > > > simply > > > because libboost_date_time-mt.so is searched for in *all* > paths > > > before > > > libboost_date_time.so. > > > > > > Anyway, I still think this is (also) a CMake issue. IMHO > it would > > > make > > > sense to turn the loop in > cmFindLibraryCommand::FindNormalLibrary() > > > inside out. What's your opinion? > > > > > > Best regards, > > > Marcel Loose. > > > > > > > > > On Thu, 2010-03-18 at 10:05 -0400, Michael Jackson wrote: > > I > > > thought there was now an option the b... > > > > > > > > > > _______________________________________________ > 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 > > _______________________________________________ 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