On Wed, Jan 5, 2011 at 5:14 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> I noticed in some build output lately that under Maverick cmake prints
> warnings like this:
>
> CMake Warning (dev) at src/node/CMakeLists.txt:2 (link_directories):
> This command specifies the relative path
>
> art_map/lib
>
> as a link directory.
>
> Policy CMP0015 is not set: link_directories() treats paths relative to the
> source dir. Run "cmake --help-policy CMP0015" for policy details. Use the
> cmake_policy command to set the policy and suppress this warning.
> This warning is for project developers. Use -Wno-dev to suppress it.
>
> I am still running Lucid and Karmic, and I do not see those warnings
> during development. The build still seems to work, AFAICT.
>
> I do use link_directories() in some places, based on these ROS build
> recommendations:
>
> http://www.ros.org/wiki/rosbuild/CMakeLists/Examples#Adding_compile_.2BAC8_link_flags
The example in that section that uses `link_directories()` is linking
against a library that's external to ROS. The warning you're getting
suggests that you're adding part of your package's directory tree to
the linker search path. That's not necessary if you're linking
against a library that you're also building in that package with
CMake. Are the libraries in `art_map/lib` built by something else?
> Are those recommendations obsolete?
>
> Some on-line sources suggest that link_directories() should no longer be used:
>
> "Don't use LINK_DIRECTORIES. Consider it deprecated. Specify the
> full path to the library instead in the TARGET_LINK_LIBRARIES call."
>
> Should we start setting absolute path names on target_link_libraries() instead?
Troy just told me about this the other day. I guess that CMake now
wants full paths to all libraries, instead of using search paths and
short names. I'm not sure that I agree with the motivation for it,
but perhaps it's the right way to go. I think that we should hold off
on changing our code until rosbuild2 comes into use with eturtle,
because it'll involve changes in how we use CMake.
brian.
(text/plain)