Cycles in message dependency graph should be detected

[furtypajohn]

Currently, if a set of messages are defined such that they create a cycle in the message dependency graph, e.g.:

Message1.msg contains:
Message2 field1

and Message2.msg contains:
Message1 field2

Message generation results in an error that looks like:

File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 321, in load_msg_depends
  load_msg_depends(msg_context, depspec, search_path)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 310, in load_msg_depends
  depspec = msg_context.get_registered(resolved_type)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 434, in get_registered
  if self.is_registered(full_msg_type):
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 423, in is_registered
  package, base_type = package_resource_name(full_msg_type)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/names.py", line 104, in package_resource_name
  val = tuple(name.split(PRN_SEPARATOR))
RuntimeError: maximum recursion depth exceeded while calling a Python object
CMake Error at /opt/ros/indigo/share/catkin/cmake/safe_execute_process.cmake:11 (message):

execute_process(/home/user/catkin_ws/build/catkin_generated/env_cached.sh
"/usr/bin/python" "/usr/bin/empy" "--raw-errors" "-F"
"/home/user/catkin_ws/build/test_messages/cmake/test_messages-genmsg-context.py"
"-o"
"/home/user/catkin_ws/build/test_messages/cmake/test_messages-genmsg.cmake"
"/opt/ros/indigo/share/genmsg/cmake/pkg-genmsg.cmake.em") returned error
code 1
Call Stack (most recent call first):
/opt/ros/indigo/share/catkin/cmake/em_expand.cmake:25 (safe_execute_process)
/opt/ros/indigo/share/genmsg/cmake/genmsg-extras.cmake:303 (em_expand)
test_messages/CMakeLists.txt:28 (generate_messages)

Cycles in the dependency graph should be specifically detected and a meaningful error should be generated rather than relying on the recursion depth error.

[tfoote]

That would be a better behavior for the user. We're not going to have time to work on it but we'd happily review a contribution along these lines.

[dirk-thomas]

Closing due to inactivity.