WilliamWoodall's profile - activity

@Thomas, yes. The rationale is that catkin provides the setup.*sh files at run time and your library is not findable without first sourcing them, so you actually should run depend on catkin. ROS packages inherit this from one of the core ROS dependencies.

This is a bug in CMake.

This workaround should not be needed in the future:

http://cmake.3232098.n2.nabble.com/OSX-deployment-target-confusion-for-2-8-10-td7582284.html

This Q/A might help explain it: http://answers.ros.org/question/52744/how-to-specify-dependencies-with-foo_msgs-catkin-packages/

Do you have the original rosdep.yaml on another machine?

If so I can put it back up in its original location. I think I might have removed the repository thinking it was no longer used.

Sorry for the inconvenience.

UDPATE:

It has been restored:

http://kforge.ros.org/rososx/homebrew/raw-file/tip/electric/rosdep.yaml

This particular error you are getting is due the fact that there is no tag which matches your version in your upstream repository.

More fundamentally, it looks like you are trying to use your upstream repository (the place where you keep your source code and do development) as your release repository. This is not generally the case, usually you have you source code for a package (say foo) at a repository like https://github.com/organization/foo.git and then you have a separate repository called the release repository where you use bloom. Normally this repository is named something like foo-release.

The appropriate work flow for bloom is that in the release repository you run git-bloom-config <URL of the upstream repo> git and then git-bloom-release rosdebian groovy. This will get the latest version of your upstream (by way of a tag matching your version, e.g. 0.0.1) and import it into the release repository. Then it will generate the debian files required for the build farm to create binary debs of your package.

This should not be a problem, I just rebuilt the desktop variant last night (with the latest XCode and brew packages) and never ran into this problem. What version of OS X and XCode are you using?

This was definitely a problem with rviz gracefully degrading on OS X. Please mark an answer so it shows up as answered. Thanks.

catkin_make --pkg joy won't work until the next release of catkin... What is in your /catkin/src directory? It looks like there was nothing to build.

You are asking to build the joy target, which doesn't exist. See:

####
#### Running command: "make -j1 joy" in "/root/catkin_ws/build"
####
make: *** No rule to make target `joy'.  Stop.
Invoking "make" failed

In stead of calling catkin_make joy simply call catkin_make and it will build everything in your workspace. In a new version of catkin_make (0.6.53+) there will be a --pkg option where you can specify individual packages from the workspace that you wish to build. See:

https://github.com/ros/catkin/pull/352

Does the file /usr/local/lib/libboost_signals-mt.dylib exist on your system? If not you may need to ensure boost is installed correctly on your system.

If you have recently reinstalled or updated boost then you might have stale build state, so you can try cleaning your CMake cache and rebuilding your packages to ensure they have up-to-date information.

Yes, CMake will ignore targets which are not defined, you could add add_dependencies(foo_node bar_does_not_exist) and it will build with no warnings.

In my example, if I run: cd build/catkin_demos/foo_msgs && make all of the messages are generated. This is basically what catkin_make --pkg foo_msgs will do: https://github.com/ros/catkin/pull/352

The reason caktin_make foo_msgs is a no-op is that there is no make target for a package by default. In stead there is a Makefile for each time project(...) is called in CMake. The correct thing to do in order to build a package is to go to its location in the build folder and invoke make.

Most likely you built your workspace, then changed something in brew (uninstalled/updated poco) and then tried to build again with out of date information.

There is no reason to call catkin_make with arguments... You are not telling catkin_make what packages you want to build you are just passing targets to make, and the project target and executable/library targets can overlap. It is better to just invoke catkin_make with no arguments.

Your projects are setup correctly (mostly), you just need to run catkin_make with no arguments.

First update foo:

cmake_minimum_required(VERSION 2.8.3)
project(foo)

find_package(catkin REQUIRED COMPONENTS foo_msgs)

catkin_package()

include_directories(include ${catkin_INCLUDE_DIRS})

add_executable(foo_node src/foo_node.cpp)
add_dependencies(foo_node foo_msgs_generate_messages_cpp)

Using add_dependencies(...) is by design or necessity, however you look at it, because we cannot know or assume that foo's targets (executables or libraries) use and therefore depend on the messages which are getting generated by foo_msgs.

Then just execute catkin_make with no arguments.

If you want to build foo_msgs explicitly (not the whole workspace) then as of pull request ros/catkin#352 you can do catkin_make --pkg foo_msgs.

Calling catkin_make foo_msgs is not sufficient because that is instructing catkin_make to invoke the foo_msgs make target which does not exist. tkruse's solution simply adds a foo_msgs target which depends on the foo_msgs_generate_messages_cpp target, allowing it to be callable and causing the foo_msgs_generate_messages_cpp target to be generated. This is not something we do by default because packages often define targets with the same name as the project which would immediately cause a conflict.

The only reliable way to build an entire package (including all of its targets) is to go to the package's build space and invoke make [all], which is what catkin_make --pkg does.

I setup an example repository here:

https://github.com/wjwwood/catkin_dem...

@arebgun That is not recommended with catkin anymore. You can continue to use rosbuild to accomplish this, but if you intend to release this package or depend on it with other catkin packages, then you'll need to follow our forthcoming 3rd-party recommendation. (recommendation will be a REP soon)

In that case, I can only guess that the state of your build is stale, please remove your build and devel folder and rebuild everything in a clean terminal environment.

Rather than explicitly exposing the CFLAGS directly, you should use catkin_package() to export from within CMake any libraries or headers to packages which depend on you.

Can you post a link to your package or put your old manifest/CMakeLists.txt up on a gist.github.com? With some more specifics I can show you exactly how this would work.

In the client package you need to find_package your 'HeaderProjectName', something like this will add the includes path from HeaderProjectName:

find_package(catkin REQUIRED COMPONENTS HeaderProjectName <other packages here>)
include_directories(${catkin_INCLUDE_DIRS})

An alternative method is that you can find_package HeaderProjectName directly:

find_package(HeaderProjectName REQUIRED)
include_directories(${HeaderProjectName_INCLUDE_DIRS})

You need to add tinyxml to your PKG_CONFIG_PATH, because tinyxml is found using pkg-config. You'll know that your environment is setup correctly when you can run pkg-config --libs tinyxml and get reasonable output.

Do you have /usr/local/lib/libPocoFoundation.dylib?

PocoFoundation is part of poco, ensure that poco is installed from homebrew (or what ever package manager you are using).

The first error can occur when you use the ros headers (ros.h) but do not link against the ros library. It might be that your package does not find_package(...) and then target_link_libraries(...) roscpp.

Edit your original question if it is related to this still, otherwise open a new issue.

Check this out for a hint out how to do this with CMake: http://code.google.com/p/yaml-cpp/issues/detail?id=127