ros / catkin Goto Github PK

A CMake-based build system that is used to build all packages in ROS.

License: BSD 3-Clause "New" or "Revised" License

CMake 42.99% Python 50.44% EmberScript 0.75% Shell 5.11% C++ 0.64% Makefile 0.07%

catkin's Introduction

Robot Operating System (ROS)
===============================================================================

ROS is a meta-operating system for your robot.  It provides
language-independent and network-transparent communication for a
distributed robot control system.

Installation Notes
------------------

For full installation instructions, including system prerequisites and
platform-specific help, see:

  http://wiki.ros.org/ROS/Installation

catkin's People

Contributors

Stargazers

Watchers

Forkers

mkjaergaard gerkey kwc ethanrublee tfoote hauptmech yasushi3 benersuay flixr housel jamuraa eitanme stonier jon-weisz smits xyuan herbrechtsmeier chadrockey vrabaud ros-windows telpr2 piyushk po1 wambamthankyoumam start-jsk sanjayankur31 kargm kyonifer otl k-okada akio meyerj scpeters hwiese1980 xqms nikolausdemmel mallouk1990 dlaz cehberlin hidof-forks miikka harmishhk jack-oquin trainman419 wyc mikepurvis requesttimedout jbohren-forks v4hn jonathanwade garaemon yuanboshe mkoval czalidis ram-z shyamalschandra aballier j-rivero uts-magic-lab bchretien 130s jakalope thaddeustaylor cmansley wkentaro mvitus sines sebastianriedel pfankhauser a20r alexhenning come-maiz ablasdel omarwalid96 metamemoryt wy342786117 ejconlon katxiao bartlettroscoe jmdaly rapyuta-robotics tabjones nizar-sallem sybotech robotpilot leokoppel fizyr-forks luojie996 jspricke gstavrinos mbs-technologie codegenerator huaixiaozi89 tiger66639 furushchev mathias-luedtke kopp peci1 sammyramone bgoldfai

catkin's Issues

Missing dependency between pkgs with msg and all gen*** pkgs

std_msgs only depends on genmsg, which allows it to be included by topologically_traverse.cmake before all gen*** pkgs have been included.

Current order is:
genmsg
genpy
gencpp
std_msgs <--- needs genpybindings!
roscpp_core
genpybindings

Correct order would be:
genmsg
genpy
gencpp
roscpp_core
genpybindings
std_msgs

test: circular dependencies amongst stacks

the error message should make sense

env hooks failed in catkin installed case

. setup.sh
bash: /tmp/build/etc/catkin/profile.d/*.all: No such file or directory

setup.py imports foreign packages, makes sourcedeb creation difficult

When building source debs, python setup files may attempt to import things that aren't installed... This is problematic
unless we install build dependencies when creating source debs...

The main trouble maker is the pattern of importing the __version__ from the package. for example here might be a typical error::

dh  clean
   dh_testdir
   dh_auto_clean
    python setup.py clean -a
Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    from genpy import __version__
  File "src/genpy/__init__.py", line 36, in <module>
    from . message import Message, SerializationError, DeserializationError, MessageException, struct_I
  File "src/genpy/message.py", line 45, in <module>
    import genmsg

python version fail

cat ../cmake/python_version.py
from future import print_function
from sys import version_info as v
print("%u.%u" % (v.major, v.minor))

In [1]: from future import print_function

In [2]: from sys import version_info as v

In [3]: print("%u.%u" % (v.major, v.minor))

AttributeError Traceback (most recent call last)

/home/work/opencv_ros/opencv/catkin/build/ in ()

AttributeError: 'tuple' object has no attribute 'major'

In [5]: v
Out[5]: (2, 6, 5, 'final', 0)

add unittest for version mismatches

unit tests for catkin where pkg A depends on specific versions of pkg B (as passed to find_package), but the right versions of B are not available. This makes sure that the foo-config-version files are being correctly generated, installed and found.

integrate testing

integration of unit tests. test results go only in build directory. Nothing is ever written to home directory. Python unit tests TBD... do we just pivot off of some definition of tests in setup.py and leave it at that?

mechanism for link of PREFIX/bin/exe to share/projname/bin/exe

catkin make installable for a single project work flow.

If i have a package that does this:

find_package(catkin)
if(catkin_FOUND)
  catkin_package(OpenCV)
endif()

Then in catkin, i should just need to do a system install to enable catkin debian builds.

recursive soft links

From mail thread.

circular symlinks in build
7 messages
Brian Gerkey <[email protected]>   Wed, Jan 4, 2012 at 5:39 PM
To: Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>, Ethan Rublee <[email protected]>
Cc: Ken Conley <[email protected]>
hi guys,

I'm seeing circular symlinks in build after running cmake, e.g.:

$ ls -l  /wg/stor1a/gerkey/code/catkin/src/build/lib/rosservice
lrwxrwxrwx 1 gerkey wgusers 74 2012-01-04 17:35
/wg/stor1a/gerkey/code/catkin/src/build/lib/rosservice ->
/wg/stor1a/gerkey/code/catkin/src/ros_comm/tools/rosservice/src/rosservice

There seems to be one such link for each build/lib/<module>.  And
there's one in src:

$ ls -l /wg/stor1a/gerkey/code/catkin/src/catkin/python/catkin
total 4
lrwxrwxrwx 1 gerkey wgusers  54 2012-01-04 17:35 catkin ->
/wg/stor1a/gerkey/code/catkin/src/catkin/python/catkin
-rw-r--r-- 1 gerkey wgusers 563 2012-01-02 13:13 __init__.py
drwxr-xr-x 2 gerkey wgusers  56 2012-01-02 13:13 sphinx

They seem to get regenerated during cmake.  Any ideas?

   brian.
Ken Conley <[email protected]>    Wed, Jan 4, 2012 at 5:41 PM
To: Brian Gerkey <[email protected]>
Cc: Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>, Ethan Rublee <[email protected]>
I also saw this in genmsg: genmsg/src/genmsg/genmsg/genmsg

Forgot about it (shelved it and was going to look back at it), thanks
for the reminder

 - Ken
[Quoted text hidden]
Brian Gerkey <[email protected]>   Wed, Jan 4, 2012 at 5:44 PM
To: Ken Conley <[email protected]>
Cc: Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>, Ethan Rublee <[email protected]>
I've seen it for the last couple of hours; am bringing it up now
because it's dramatically slowing down test runs, due to rospack
having to recurse until some boost::filesystem max-symlink limit is
hit (repeatedly).

   brian.
[Quoted text hidden]
--
http://brian.gerkey.org
Ken Conley <[email protected]>    Wed, Jan 4, 2012 at 9:04 PM
To: Brian Gerkey <[email protected]>
Cc: Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>, Ethan Rublee <[email protected]>
Another example:

Traceback (most recent call last):
 File "/usr/lib/python2.6/unittest.py", line 279, in run
   testMethod()
 File "/usr/local/lib/python2.6/dist-packages/nose/loader.py", line
390, in loadTestsFromName
   addr.filename, addr.module)
 File "/usr/local/lib/python2.6/dist-packages/nose/importer.py", line
39, in importFromPath
   return self.importFromDir(dir_path, fqname)
 File "/usr/local/lib/python2.6/dist-packages/nose/importer.py", line
86, in importFromDir
   mod = load_module(part_fqname, fh, filename, desc)
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/test/test_roslaunch_child.py",
line 40, in <module>
   import roslaunch.child
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
   from . import param_dump as roslaunch_param_dump
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/param_dump.py",
line 40, in <module>
   import roslaunch.config
 File "/u/kwc/fuerte/src/ros_comm/tools/roslaunch/src/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/roslaunch/__init__.py",
line 43, in <module>
[Quoted text hidden]
Ethan Rublee <[email protected]>  Thu, Jan 5, 2012 at 7:43 AM
To: Ken Conley <[email protected]>
Cc: Brian Gerkey <[email protected]>, Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>
Looking into this:

~/catkin$ git grep "ln"
cmake/enable_python.cmake:      execute_process(COMMAND /bin/ln -sf
cmake/enable_python.cmake:        execute_process(COMMAND /bin/ln -sf
...
[Quoted text hidden]
Ethan Rublee <[email protected]>  Thu, Jan 5, 2012 at 7:55 AM
To: Ken Conley <[email protected]>
Cc: Brian Gerkey <[email protected]>, Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>
Its one of those lines in enable_python that is the culprit. Commented them out and there is no soft link.

Digging deeper.
[Quoted text hidden]
Ethan Rublee <[email protected]>  Thu, Jan 5, 2012 at 7:58 AM
To: Ken Conley <[email protected]>
Cc: Brian Gerkey <[email protected]>, Troy Straszheim <[email protected]>, Morten Kjærgaard <[email protected]>
diff --git a/cmake/enable_python.cmake b/cmake/enable_python.cmake
index 858111e..2bcb260 100644
--- a/cmake/enable_python.cmake
+++ b/cmake/enable_python.cmake
@@ -68,8 +68,8 @@ function(catkin_export_python)

     foreach(pkg ${${pkg_name}_PACKAGES})
       get_filename_component(name ${pkg} NAME)
-      execute_process(COMMAND /bin/ln -sf
-        ${CMAKE_CURRENT_SOURCE_DIR}/${pkg} ${CMAKE_BINARY_DIR}/lib/${name})
+      #execute_process(COMMAND /bin/ln -sf
+      #  ${CMAKE_CURRENT_SOURCE_DIR}/${pkg} ${CMAKE_BINARY_DIR}/lib/${name})
     endforeach()

     foreach(script ${${pkg_name}_SCRIPTS})

The offending line.  Still need to dig a bit more as to why this causes a recursive link.
[Quoted text hidden]

easy signing of source debs.

install lists of messages/servs/etc

so that custom generators can use installed messages via cmake variables.

Document how to disable "ros-fuerte" prefix for binaries.

We now have backports of eigen and protobuf which are prefixed with ros-fuerte because we don't know how to turn this off. Even though they are intended as pure backport system installations.

message generation currently broken

In a brand new build, it appears the init.py creation is going in the wrong projects. When I do the first "cmake ../src", I see directories with init.py thunks in gen/py for projects like catkin and ros_comm, which have no messages, but I don't see any directories for projects like std_msgs, which do. When I run "make", the messages for std_msgs get created, but there is no init.py, so "import std_msgs.msg" does not work. This is currently blocking integration.

per-package modifications to PREFIX/etc/profile.d

rosdep resolution

test_basics only works with natty

from a lucid system:
[/home/local/catkin_test/catkin/test]$ nosetests

FAIL: test_basics.test_tiny
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/nose-1.1.2-py2.6.egg/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/local/catkin_test/catkin/test/test_basics.py", line 45, in test_tiny
    "catkin-test-nolangs_3.4.5~natty_source.changes")
  File "/home/local/catkin_test/catkin/test/catkintest/__init__.py", line 89, in assert_exists
    assert exists(p), "%s doesn't exist" % p
AssertionError: /home/local/catkin_test/catkin/test/src/catkin-test-nolangs_3.4.5~natty.dsc doesn't exist
    '/home/local/catkin_test/catkin/test/src/catkin-test-nolangs_3.4.5~natty.dsc' = <module 'os' from '/usr/lib/python2.6/os.pyc'>.path.join('/home/local/catkin_test/catkin/test/src', 'catkin-test-nolangs_3.4.5~natty.dsc')
    print "Checking for", '/home/local/catkin_test/catkin/test/src/catkin-test-nolangs_3.4.5~natty.dsc'
>>  assert exists('/home/local/catkin_test/catkin/test/src/catkin-test-nolangs_3.4.5~natty.dsc'), "%s doesn't exist" % '/home/local/catkin_test/catkin/test/src/catkin-test-nolangs_3.4.5~natty.dsc'

PYTHON_PACKAGES_DIR not found in release scripts

rather than if(APPLE) telling us about the platform, we should just depend on python's platform package.

install fails to install python package catkin

I did a make install of catkin, and attempted to use it to build a debian.

My failure

$ make OpenCV-gendebian 
Scanning dependencies of target OpenCV-gendebian
Generating /home/work/opencv_ros/opencv/debian/control, /home/work/opencv_ros/opencv/debian/rules, /home/work/opencv_ros/opencv/debian/changelog, /home/work/opencv_ros/opencv/debian/copyright
Traceback (most recent call last):
  File "/usr/local/share/cmake/catkin/catkin_generate_debian.py", line 4, in <module>
    import sys, yaml, pprint, em, os.path, datetime, dateutil.tz, platform, catkin
ImportError: No module named catkin

Are you missing a setup.py in the root of catkin?

Install manifest

/usr/local/share/cmake/catkin/catkin-config.cmake
/usr/local/share/cmake/catkin/catkin-config-version.cmake
/usr/local/share/cmake/ROS/ros-config-version.cmake
/usr/local/share/cmake/ROS/ros-config.cmake
/usr/local/share/cmake/catkin/em/control.em
/usr/local/share/cmake/catkin/em/rules.python_distutils.em
/usr/local/share/cmake/catkin/em/rules.cmake.em
/usr/local/share/cmake/catkin/em/copyright.willowgarage.em
/usr/local/share/cmake/catkin/em/changelog.em
/usr/local/share/cmake/catkin/setup.zsh.in
/usr/local/share/cmake/catkin/assert.cmake
/usr/local/share/cmake/catkin/enable_python.cmake
/usr/local/share/cmake/catkin/wg_python.cmake
/usr/local/share/cmake/catkin/pkg-config-version.cmake.in
/usr/local/share/cmake/catkin/python_distutils_install.sh.in
/usr/local/share/cmake/catkin/safe_execute_process.cmake
/usr/local/share/cmake/catkin/log.cmake
/usr/local/share/cmake/catkin/install_cmake_infrastructure.cmake
/usr/local/share/cmake/catkin/install_cmake_config_version.cmake
/usr/local/share/cmake/catkin/empy_util.py
/usr/local/share/cmake/catkin/__init__.py.in
/usr/local/share/cmake/catkin/set_once.cmake
/usr/local/share/cmake/catkin/catkin_workspace.cmake
/usr/local/share/cmake/catkin/env.sh.in
/usr/local/share/cmake/catkin/topologically_traverse.py.in
/usr/local/share/cmake/catkin/pkg-config.cmake.in
/usr/local/share/cmake/catkin/python_version.py
/usr/local/share/cmake/catkin/all.cmake
/usr/local/share/cmake/catkin/catkin-config.cmake.in
/usr/local/share/cmake/catkin/empy.cmake
/usr/local/share/cmake/catkin/setup.bash.in
/usr/local/share/cmake/catkin/parse_arguments.cmake
/usr/local/share/cmake/catkin/python.cmake
/usr/local/share/cmake/catkin/catkin-context.in
/usr/local/share/cmake/catkin/catkin_generate_debian.py
/usr/local/share/cmake/catkin/find_program_required.cmake
/usr/local/share/cmake/catkin/setup.sh.in
/usr/local/share/cmake/catkin/langs.cmake
/usr/local/share/cmake/catkin/em_expand.cmake
/usr/local/share/cmake/catkin/shell.cmake
/usr/local/share/cmake/catkin/stamp.cmake
/usr/local/share/cmake/catkin/topologically_traverse.cmake.em
/usr/local/share/cmake/catkin/debian-util.cmake
/usr/local/share/cmake/catkin/catkin_EXTRAS_DIR
/usr/local/setup.sh
/usr/local/setup.bash
/usr/local/setup.zsh
/usr/local/env.sh

There are duplicate em files in catkin

bin/em/* all exist in cmake/em and in bin they've been updated more recently. I expect they were moved, but the old copy's not cleaned up.

rosdep integration

stack.yaml's dependencies should be rosdep keys that get expanded to correct values for the chosen platform when .dscs are built

install_cmake_infrastructure libraries

Attempting to port ecto's build system to catkin, i run into this problem with the cmake infrastructure.

Here is my use of the function:

install_cmake_infrastructure(ecto
  VERSION 0.0.1
  INCLUDE_DIRS include
  LIBRARIES ecto
  )

Here is the error

CMake Error at catkin/cmake/install_cmake_infrastructure.cmake:163 (install):
  install TARGETS given target "ecto" which does not exist in this directory.
Call Stack (most recent call first):
  ecto/CMakeLists.txt:88 (install_cmake_infrastructure)

My ecto target is declared in src/lib/CMakeLists.txt, while i'm tempted to put the install_cmake_infrastructure in the top level. Apparently the install(TARGETS ...) command will only look for targets in the current cmake file...

Brainstorm here:
install_cmake_infrastructure should not be used to create the install targets. It should be used to declare configuration related things. Everything necessary to generate the config.cmake and version files:

where are my includes
what are my library names
what is my python path
version
special flags
header include dependencies (e.g. boost and python.h)
cmake extras location
etc...

Another function should be used, possibly just vanilla cmake for installation of targets.

Another possibility is the use of the export(...) and install(EXPORT ...) cmake functions which appear to be a native way for exporting targets for use by other projects.

cmake/rosbuild_compat.cmake:set(ENV{ROS_ROOT} ${CMAKE_SOURCE_DIR}/ros)

Setting of ROS_ROOT environment variable is painful for projects that depend on this being the system ros_root... Can't this be optional?

pkg-config infrastructure autoinstall

catkin should install working pkg-config infrastructure as well

catkin_export_python adds src directory even if it doesn't exist

The overloading of catkin_export_python for both setup.py and paths, as well as its use in message packages appears to cause this very frequent warning in the builds:

CMake Warning at catkin/cmake/catkin_export_python.cmake:22 (message):
catkin_export_python: Python directory
/home/rosbuild/hudson/workspace/catkin-wet.PLEASE.DONT.BREAK.THIS.BUILD/src/ros_comm/src
not found
Call Stack (most recent call first):
ros_comm/CMakeLists.txt:24 (catkin_export_python)

and for messages:

catkin_export_python: Python directory
/home/rosbuild/hudson/workspace/catkin-wet.PLEASE.DONT.BREAK.THIS.BUILD/src/common_msgs/actionlib_msgs/src
not found
Call Stack (most recent call first):
/home/rosbuild/hudson/workspace/catkin-wet.PLEASE.DONT.BREAK.THIS.BUILD/build/cmake/genpy/genpy-extras.cmake:85 (catkin_export_python)
/home/rosbuild/hudson/workspace/catkin-wet.PLEASE.DONT.BREAK.THIS.BUILD/build/common_msgs/actionlib_msgs/cmake/actionlib_msgs-genmsg.cmake:44 (_generate_module_py)
catkin/cmake/em_expand.cmake:26 (include)
/home/rosbuild/hudson/workspace/catkin-wet.PLEASE.DONT.BREAK.THIS.BUILD/build/cmake/genmsg/genmsg-extras.cmake:97 (em_expand)
common_msgs/actionlib_msgs/catkin.cmake:11 (generate_messages)
common_msgs/actionlib_msgs/CMakeLists.txt:2 (include)

result of find_package(ROS ...) is easily overwritten by a few macro calls

It appears that generate_messages can overwrite the result of a previous call to find_package(ROS ...) leading to non obvious linker errors....

Invalid init.py thunker generated

Filing here -- haven't figure out conditions in which this occurred, but not the __extended_path is empty, which means this thunker generates an infinite import loop.

from pkgutil import extend_path
import sys, os
__extended_path = ""
sys.path += [__extended_path]
__path__ = extend_path(__path__, __name__)

import os.path
src_init_file = os.path.join(__extended_path, __name__ + '.py')
if os.path.isfile(src_init_file):
    execfile(src_init_file)
else:
    src_init_file = os.path.join(__extended_path, __name__, '__init__.py')
    if os.path.isfile(src_init_file):
        execfile(src_init_file)

verifyheaders installalbe to e.g. /usr/include/ros-fuerte/std_msgs when not in /opt/ros/fuerte mode

catkin-generate-debian should fail if required keys not set

sourcedebs just failed due to invalid changelog. Looking at it, it appears the template doesn't validate that the author name is set.

Invalid changelog:

ros-fuerte-ros-tutorials (0.2.7-0oneiric) oneiric; urgency=high

  * autogenerated

 --   Tue, 24 Jan 2012 15:34:12 -0800

Good changelog:

ros-fuerte-ros (1.7.7-0oneiric) oneiric; urgency=high

  * autogenerated

 -- Ken Conley <[email protected]>  Tue, 24 Jan 2012 14:26:10 -0800

catkin-generate-debians on the eigen repository does not respect --debian_inc option values

It just produces 0codename packages.

install fails on OSX

On OSX (10.7.2, Python 2.7.1), 'make install' yields:

COMMAND=
+ '[' -n '' ']'
+ cd /Users/gerkey/code/catkin/src/catkin
+ /usr/bin/env PYTHONPATH=/Users/gerkey/code/catkin/src/catkin/python:/tmp/catkin/lib/python2.7/dist-packages:/Users/gerkey/code/catkin/src/build/gen/py /usr/bin/python /Users/gerkey/code/catkin/src/catkin/setup.py install --install-layout=deb --prefix=/tmp/catkin
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --install-layout not recognized
CMake Error at catkin/CMakeFiles/safe_execute_install.cmake:5 (message):
  Error executing process with arguments
Call Stack (most recent call first):
  catkin/cmake_install.cmake:106 (INCLUDE)
  cmake_install.cmake:32 (INCLUDE)


make: *** [install] Error 1

Removing the --install-layout=deb line from cmake/templates/python_distutils_install.sh.in gets further but results in a different error:

COMMAND=
+ '[' -n '' ']'
+ cd /Users/gerkey/code/catkin/src/genpy
+ /usr/bin/env PYTHONPATH=/Users/gerkey/code/catkin/src/genpy/src:/tmp/catkin/lib/python2.7/dist-packages:/Users/gerkey/code/catkin/src/build/gen/py /usr/bin/python /Users/gerkey/code/catkin/src/genpy/setup.py install --prefix=/tmp/catkin
running install
Checking .pth file support in /tmp/catkin/lib/python2.7/site-packages/
/usr/bin/python -E -c pass
TEST FAILED: /tmp/catkin/lib/python2.7/site-packages/ does NOT support .pth files
error: bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /tmp/catkin/lib/python2.7/site-packages/

and your PYTHONPATH environment variable currently contains:

    '/Users/gerkey/code/catkin/src/genpy/src:/tmp/catkin/lib/python2.7/dist-packages:/Users/gerkey/code/catkin/src/build/gen/py'

Here are some of your options for correcting the problem:

* You can choose a different installation directory, i.e., one that is
  on PYTHONPATH or supports .pth files

* You can add the installation directory to the PYTHONPATH environment
  variable.  (It must then also be on PYTHONPATH whenever you run
  Python and want to use the package(s) you are installing.)

* You can set up the installation directory to support ".pth" files by
  using one of the approaches described here:

  http://peak.telecommunity.com/EasyInstall.html#custom-installation-locations

Please make the appropriate changes for your system and try again.
CMake Error at genpy/CMakeFiles/safe_execute_install.cmake:5 (message):
  Error executing process with arguments
Call Stack (most recent call first):
  genpy/cmake_install.cmake:51 (INCLUDE)
  cmake_install.cmake:34 (INCLUDE)


make: *** [install] Error 1

error hard on missing files in stack.yaml

Catkin-ChangelogType: +changlogz.em
Catkin-DebRulesType: +rules.em

configuration dependencies

If my project depends on A B and C catkin projects, need to auto find_package these in my config.cmake file.

Also, if i depend on boost or some other library, this must also be added to my config.cmake file.

DOCS

vcs support

Detect vcs for things such as git tag's and revision numbers. Useful for docs and such.

multiple debs per stack: -dbg, -doc, -dev

doc building targets

something like

sphinx(my_project
  DOC_SOURCE_DIR
  DOC_OUTPUT_DIR
 ...
)

or

doxygen(my_project
 ...
)

Use intersphinx for referring to other docs.

catkin-generate-debian added a lot of build artifacts to my gbp project

https://github.com/wg-debs/gazebo/commit/34bb19ea63b0d9299328c9ddd9643b566d567bcd

I know I didn't clean, but this seems like it should prompt or warn or something. And possibly work outside the git workspace to avoid this problem.

build can pull code from old install

This build: http://hudson:8080/job/catkin-dry-on-wet.fat.oneiric.amd64/27/console
has this error:
[ 6%] Generating Orocos Typelib XML code from std_msgs/Bool.msg
Traceback (most recent call last):
File "/home/jenkins/workspace/catkin-dry-on-wet.fat.oneiric.amd64/install/bin/gen_typelibxml.py", line 4, in
import pkg_resources
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2672, in
working_set.require(requires)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 654, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 552, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: gentypelibxml==0.0.2
make[2]: *** [gen/typelibxml/std_msgs/Bool.xml] Error 1
make[1]: *** [std_msgs/CMakeFiles/std_msgs_gentypelibxml.dir/all] Error 2
make: *** [all] Error 2

The source dir is /home/jenkins/workspace/catkin-dry-on-wet.fat.oneiric.amd64/src, the build dir is /home/jenkins/workspace/catkin-dry-on-wet.fat.oneiric.amd64/build, and the install dir is /home/jenkins/workspace/catkin-dry-on-wet.fat.oneiric.amd64/install. Looks like the build is failing with an error in the previously installed code.

fix usage git-catkin-set-upstream

debian creation for rosdistro should take into consideration target debian distros

Services are not generated into correct 'srv' subdirectory and clobber 'msg' generation

Services being generated into 'msg' submodule instead:

$ ls std_srvs/
init.py msg

test_rospy has both msg and srv generation, and the srv generation is clobbering out the msg files (note 'Srv'' in class names):

$ ls test_rospy/msg/
_ArrayVal.py _HeaderHeaderVal.py _TestConstants.py
_ConstantsMultiplex.py _HeaderVal.py _TestFixedArray.py
_EmbedTest.py init.py _TransitiveImport.py
_EmptyReqSrv.py _ListReturn.py _TransitiveMsg1.py
_EmptyRespSrv.py _MultipleAddTwoInts.py _TransitiveMsg2.py
_EmptySrv.py _PythonKeyword.py _TransitiveSrv.py
_Floats.py _StringString.py _Val.py

give meaning full error message on missing upstream tag

git-catkin-import-upstream

Receiving objects: 100% (195/195), 23.50 KiB, done.
Resolving deltas: 100% (96/96), done.
Upstream's stack.yaml has version 0.4.2
Upstream's name is std_msgs
fatal: Not a valid object name

installing of debian's fail due to env hook scripts

Installed catkin, then installed genmsg...


dpkg: error processing ../ros-fuerte-genmsg_0.2.1-0oneiric_amd64.deb (--install):
 trying to overwrite '/opt/ros/fuerte/setup.zsh', which is also in package ros-fuerte-catkin 0.2.1-0oneiric
Errors were encountered while processing:
 ../ros-fuerte-genmsg_0.2.1-0oneiric_amd64.deb

empy scripts prefer system installed Python libraries instead of workspace

I pip installed genmsg and forgot to remove it before building with catkin. I got fairly opaque error messages from catkin/empy that turned out to be because it was using the pip version of genmsg. It seems that catkin should assert the primacy of its own Python path.

Need a standard way of detecting PREFIX (e.g. for locating etc)

In order to use /etc/ , need to be able to locate it in a prefix install. May also be useful for locating other relative paths.

requirement for directories to have the same name as specified in stack.yaml : Catkin-Projectname

This seems to be arbitrary.

If my project is "ecto_opencv" and locally it exists in a directory named opencv, catkin can't handle it. Seems like catkin shouldn't require the project name to be the same as the directory name.

Is there some good reason for this?