[ros-users] CMake problem on NFS-mounted directories

[Mrinal Kalakrishnan]

I just wanted to add that adding the line "project(foo)" before
rosbuild_init() in my CMakeLists.txt fixes the problem. But most ROS
packages don't seem to have this line - I'm just trying to understand
how the system works without it.

Thanks,
Mrinal

On Tue, Oct 12, 2010 at 9:22 PM, Mrinal Kalakrishnan <mail at mrinal.net> wrote:
> Hi all,
>
> I have a problem compiling ROS packages when the package is located in
> an NFS-mounted directory. I just created a new package using
> roscreate-pkg, and then when I run make, this is what I get:
>
> --------------------------------------------------------------------------------------------------------------------------------
> mkdir -p bin
> cd build && cmake -Wdev -DCMAKE_TOOLCHAIN_FILE=`rospack find
> rosbuild`/rostoolchain.cmake  ..
> CMake Error at /opt/ros/cturtle/ros/core/rosbuild/public.cmake:136
> (get_filename_component):
>  get_filename_component called with incorrect number of arguments
> Call Stack (most recent call first):
>  CMakeLists.txt:12 (rosbuild_init)
> --------------------------------------------------------------------------------------------------------------------------------
>
> Looking into public.cmake:136, I see this code:
>
> --------------------------------------------------------------------------------------------------------------------------------
>  get_filename_component(_project ${PROJECT_SOURCE_DIR} NAME)
>  message("[rosbuild] Building package ${_project}")
>
>  project(${_project})
> --------------------------------------------------------------------------------------------------------------------------------
>
> It turns out that ${PROJECT_SOURCE_DIR} is empty when
> get_filename_component() is called. As far as the CMake documentation
> goes, PROJECT_SOURCE_DIR is set by the project() command, which is
> only called 3 lines after it's being used here. I don't understand how
> this works normally. When I create my package on a local drive
> instead, ${PROJECT_SOURCE_DIR} is already valid when it comes to that
> line in the code, so it works just fine.
>
> Any help would be appreciated. Thanks in advance,
> - Mrinal
>