Hello Philip, > The change in library directory semantics is fairly low-key. You can > see an example of the differences below. The big difference is that > DLLs will be placed in CMAKE_RUNTIME_OUTPUT_DIRECTORY. I'm not sure how > this affects the PREFIX target property that CMake uses now for DLL > placement. Someone would need to test this. > > I do know EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH are completely > backwards compatible, merely deprecated in CMake 2.6.
Perhaps the "library directory semantics" is not the right term. I refer to Policy CMP0003 (http://www.cmake.org/HTML/cmake-2.6.html#command_CMP0003) where libraries which are referred to by path name in target_link_libraries() lines will not be added to the linker options in the same way in CMake 2.4.x and 2.6.x+... I tried troubleshooting this a bit, but my CMake expertise leaves a bit to be desired I'm afraid. But I'll try to describe the symptoms I saw and the steps I tried to take to fix them. With the current OSG CMake config, with CMake 2.7.x, the generated project files contain ..\..\lib\OpenThreads ..\..\lib\osg (etc.) in the Linker - Input - Additional Dependencies field. This is wrong for two reasons: first the path should not be there, but in the Linker - General - Additional Library Directories field; second, the libs need a .lib extension or else VS tries to link with OpenThreads.obj and osg.obj instead of OpenThreads.lib and osg.lib. When generating the build files with CMake 2.4.x, that's what I get (i.e. no paths and .lib extension), and it works no problem. Now, when I first generated the build files, CMake gave me a warning about policy CMP0003, so I looked it up. It suggests two ways to go forward, one is to make it revert to the old behavior and the other is to fix it in our project files. I first tried to set cmake_policy(SET CMP0003 OLD) in the root CMakeLists.txt, which should make it revert to the old behavior. This seemed to have little to no effect (the generated project files still did not have the right library names, nor did they have extensions). I then tried to fix the CMake files we have. The docs say you should replace add_executable(myexe myexe.c) target_link_libraries(myexe /path/to/libA.so B) by link_directories(/path/to) # needed to find library B add_executable(myexe myexe.c) target_link_libraries(myexe /path/to/libA.so B) But that's a bit hard in our case, because the add_library line (in our case) is in a separate part of the source than the target_link_libraries line, so it's hard to put the link_directories before the add_library (which is required, or else CMake gives me an error). It would require changing the LINK_INTERNAL macro we have in CMakeModules/OsgMacroUtils.cmake. I could do it, but I would feel better if someone with more CMake knowledge did it. Anyways, that's my comprehension of the issue. CMake experts might find a fix really quickly, but with my limited CMake knowledge, I can't really go any further than that. I encourage you to try it - download the CMake 2.7.x CVS snapshot and try to generate the Visual Studio project files from the OSG CMake config. You might find something I overlooked. Thanks, J-S -- ______________________________________________________ Jean-Sebastien Guay [EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
