Make eclipse-project does not work properly with rosbuild anymore

[ipa-rmb]

Since the last updates for ROS groovy on ubuntu 12.04 "make eclipse-project" appears not to work properly with the old rosbuild system anymore. It terminates with the following error:

make eclipse-project
mv Makefile Makefile.ros
if ! (cmake -G"Eclipse CDT4 - Unix Makefiles" -Wno-dev . && rm Makefile && rm CMakeCache.txt && rm -rf CMakeFiles); then mv Makefile.ros Makefile && echo "ERROR building Eclipse project!" && false; fi
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Could not determine Eclipse version, assuming at least 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong.
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
[rosbuild] Building package hermes_scenario
[rosbuild] Cached build flags older than manifests; calling rospack to get flags
-- Using CATKIN_DEVEL_PREFIX: /home/rbormann/git/hermes/hermes_scenario/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/groovy
-- This workspace overlays: /opt/ros/groovy
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found gtest sources under '/usr/src/gtest': gtests will be built
-- Using CATKIN_TEST_RESULTS_DIR: /home/rbormann/git/hermes/hermes_scenario/test_results
-- catkin 0.5.65
[rosbuild] Including /opt/ros/groovy/share/roscpp/rosbuild/roscpp.cmake
[rosbuild] Including /opt/ros/groovy/share/rospy/rosbuild/rospy.cmake
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rbormann/git/hermes/hermes_scenario
mv Makefile.ros Makefile
mv .project .project-cmake
awk -f /opt/ros/groovy/share/mk/eclipse.awk .project-cmake > .project
rm .project-cmake
python /opt/ros/groovy/share/mk/make_pydev_project.py
Creating pydev project for package 'hermes_scenario'
Traceback (most recent call last):
File "/opt/ros/groovy/share/mk/make_pydev_project.py", line 39, in
import roslib; roslib.load_manifest(PKG)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslib/launcher.py", line 62, in load_manifest
sys.path = _generate_python_path(package_name, _rospack) + sys.path
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslib/launcher.py", line 93, in _generate_python_path
m = rospack.get_manifest(pkg)
File "/usr/lib/pymodules/python2.7/rospkg/rospack.py", line 136, in get_manifest
return self._load_manifest(name)
File "/usr/lib/pymodules/python2.7/rospkg/rospack.py", line 175, in _load_manifest
retval = self._manifests[name] = parse_manifest_file(self.get_path(name), self._manifest_name)
File "/usr/lib/pymodules/python2.7/rospkg/rospack.py", line 167, in get_path
raise ResourceNotFound(name, ros_paths=self._ros_paths)
rospkg.common.ResourceNotFound: hermes_scenario
ROS path [0]=/opt/ros/groovy/share/ros
...
ROS path [18]=/opt/ros/groovy/share
ROS path [19]=/opt/ros/groovy/stacks
make: *** [eclipse-project] Error 1

Moreover, afterwards, roscd does still work but rosmake and roslaunch do not find the package anymore. There are several additional catkin folders created inside the package folder. If you delete then with:

rm -r catkin catkin_generated CATKIN_IGNORE devel gtest test_results

everything works well again. Even the eclipse project can be imported in the IDE, anyways.
Is this wanted behaviour, or would it maybe make sense to still provide an "make eclipse-project-rosbuild" option for those packages built with rosbuild?

[dirk-thomas]

Neither rosbuild nor the eclipse-project target are relelated to catkin - therefore closing this issue.

Please see the duplicate issue at ros/ros#20.