Force Rebuild of Base Package

asked 2014-01-28 04:58:38 -0500

Constantin S
296 ●17 ●19 ●31

updated 2014-01-28 08:50:55 -0500

All, I want to add some debug statements to fake_localization for some tests. I can't get the build system to build it. This is very aggravating:

Adjust $ROS_PACKAGE_PATH to hold my packages first
roscd fake_localization moves me to my local sources
rosmake complains about ROS_NOBUILD
find /opt/ros -iname '*ROS_NOBUILD*' returns nothing
find /home/me/workspace/navigation -iname '*ROS_NOBUILD*' returns nothing

There is no ROS_NOBUILD in my directory. There is no documentation explaining where this ROS_NOBUILD is coming. I am having trouble finding documentation on how to remove supplied packages from the original installation due to the this strange organization of ../share and ../include and ../bin folders in ros root.

I managed to build it, it was a catkin issue. However, to setup an entire workspace for catkin builds and move all my projects into a src folder is redundant to me. My solution:

roscd fake_localization
mkdir build
cd build
cmake ..
make

Finally you need to move the executable out of the build directory otherwise rosrun will not find it...

cp devel/lib/fake_localization/fake_localization ..

cmake -DCMAKE_INSTALL_PREFIX=../bin ..
make install

But the second option adds all these bloated scripts in the bin directory. (But rosrun will find it).

edit retag flag offensive close merge delete

Comments

What version of ROS are you using?

joq ( 2014-01-28 06:11:17 -0500 )edit

Hydro - I managed to build it - this was a catkin issue.

Constantin S ( 2014-01-28 06:29:05 -0500 )edit

add a comment

answered 2014-01-28 07:53:33 -0500

William

17335 ●101 ●182 ●262 http://wjwwood.io/

In Hydro fake_localization is not a rosbuild package so rosmake isn't going to work.

The "strange" organization of ../bin, ../include and ../share is called FHS:

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

And is the recommended way of installing files in linux.

But the second option adds all these bloated scripts in the bin directory.

You shouldn't set your CMAKE_INSTALL_PREFIX to a bin folder.

The bloated scripts you are referring to are there to help you extend your environment by running source path/to/bloated/scripts/setup.bash you will have that path extended on to your PATH, PYTHONPATH, CMAKE_PREFIX_PATH, PKG_CONFIG_PATH, etc... However, if you do not want to use them, simply pass -DCATKIN_BUILD_BINARY_PACKAGE="1" to cmake and catkin will not generate them. They are on by default because most people find them useful.

Finally you need to move the executable out of the build directory for who knows why ...

You don't need to move anything. You can either set the CMAKE_INSTALL_PREFIX to something already on your path, like /usr or /usr/local, or you can source the resulting setup.bash file, e.g. source devel/setup.bash.

However, to setup an entire workspace for catkin builds and move all my sources in a weird hierarchy is completely unacceptable to me.

So, what weird hierarchy are you referring to, the default suggestion to put source code under the src folder? If you do not want to do that you can organize your code how ever you like. If you can you describe to me how you like your source to be setup and then I can probably tell you how to build them in that layout.

In the simplest form you can just source whatever workspace you have navigation in, i.e. source /opt/ros/hydro/setup.bash or source /home/me/workspace/navigation/.../setup.bash. And then build fake_localization as if it were a normal CMake project:

source /opt/ros/hydro/setup.bash
cd /path/to/fake_localization_source
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=./install
make
make install
source ./install/setup.bash
rosrun ...

I have found catkin to be quite conventional and that it imposes very few requirements on your workflow, but that's just my opinion. I hope this answer helps you with your problems and allows you to use catkin however you like.

edit flag offensive delete link

Comments

I appreciate the answer, it's very indepth. What is the point of the new shell scripts? Is the old standard of setting your `ROS_PACKAGE_PATH` in the `.bashrc` not necessary anymore? My typical workflow - as I work on tons of projects - is to have a `workspace/[project]` folder with 'src' and `include` folders. Now I need a `workspace/src/project/src` folder? That is my frustration with a "catkin" workspace. I don't see the advantages of catkin over rosbuild - which was a great system.

Constantin S ( 2014-01-28 08:41:31 -0500 )edit

Also where is the documentation for this magical CATKIN_BUILD_BINARY_PACKAGE ... Here's your documentation: http://docs.ros.org/api/catkin/html/user_guide/variables.html

Constantin S ( 2014-01-28 08:44:04 -0500 )edit

The shell scripts are created for each "devel" or "install" space. The scripts do two things, firs they add their space to the important ROS agnostic environment variables like PATH, PYTHONPATH, etc... `rosbuild` never set these, which is why tools like `rosrun` are necessary and it is why all python scripts had to start with `import roslib; roslib.load_manifest('pkg_name')`. The other thing they do is allow packages to add environment hooks, through these hooks things like `ROS_PACKAGE_PATH`, `ROS_DISTRO` and other things can be set. So sourcing them is important and that's why they are on by default. That is also why the `CATKIN_BUILD_BINARY_PACKAGE` is not very well documented, because it is basically only used for building binary packages where those files aren't needed for each binary package.

William ( 2014-01-28 09:56:19 -0500 )edit

I'm not going to go into every reason we decided to use `catkin` instead of `rosbuild`, and so all I will say is that we recommend you setup catkin workspaces this way for good reasons and I recommend you do that. If you still want to use `rosbuild` for your packages and do not care about releasing them, then that's fine too.

William ( 2014-01-28 09:59:32 -0500 )edit

William, thank you for the responses. They are very enlightening. I have every intention to use catkin as expected/suggested in my upcoming projects. My final question is, in the catkin workspace does the folder have to be called "src"? TIA

Constantin S ( 2014-01-28 11:16:57 -0500 )edit

No, you can specify the source space to the `catkin_make_*` family of tools using the `--source` option. If you are building your catkin workspace using just cmake (no special tools) then a workspace is simply any folder where you have called `catkin_init_workspace` (which symbolically links a boiler plate `CMakeLists.txt` to the current directory). The boiler plate `CMakeLists.txt` basically finds all the packages below it, and calls CMake's `add_subdir` on each of them.

William ( 2014-01-28 12:11:29 -0500 )edit

William, I have been playing around with catkin today using the navigation stack source. I can not for the life of me get it to run my fake_localization. roslaunch and rosrun complain about not being able to find my new fake_localization. I can't source the setup.bash in devel because it overwrites my ros path. I need that to remain the same as I have older rosbuild packages that need to be run from a launch file.

Constantin S ( 2014-01-29 08:20:43 -0500 )edit

What environment variables do I need to set so rosrun finds the binary in devel/lib ? Thanks in advance!

Constantin S ( 2014-01-29 08:27:50 -0500 )edit

see more comments

Force Rebuild of Base Package

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Force Rebuild of Base Package edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Force Rebuild of Base Package