CMAKE_PREFIX_PATH issue with ros_comm

[nschoe]

Hi @akru sorry it's me again (I hope I'm helping making things go further will all this).

It seems I have an issue with ros_comm package concerning the CMAKE_PREFIX_PATH.

Here is a simple shell.nix file:

with import /home/nschoe/airapkgs {};

stdenv.mkDerivation {
  name = "papyrus-kheops-env";

  buildInputs = [
                  diagnostic_msgs
                  ros_comm
                ];

  shellHook = ''
    printf ${ros_comm}
  '';
}

A very simple file with just ros_comm and diagnostic_msgs as dependencies.

Enter the shell with nix-shell.
Verify that CMAKE_PREFIX_PATH does have diagnostic_msgs inside:

$> echo $CMAKE_PREFIX_PATH  | grep --color=auto diagnostic_msgs
[snip] /nix/store/hhrybrzqxp6zb080xg4g5d946yg436x8-diagnostic_msgs-1.12.6 [snip]

(the list is huge_ so I redacted it, but grepping it finds it).

Now source the setup.bash of package ros_comm (I believe this is the normal operation to run anything ROS-related):

source /nix/store/cs6lnrddrqr3d5fh9q9vra2mwi52x8h2-ros_comm-1.14.4/setup.bash

And now, diagnostic_msgs disappeared from CMAKE_PREFIX_PATH:

$> echo $CMAKE_PREFIX_PATH  | grep --color=auto diagnostic_msgs
(empty return)

My intuition is that it's related to the recent migration, I'll try changing the version back to a previous one and see if this helps.

[akru]

ros_comm have no diagnostic_msgs in dependencies, why diagnostic_msgs should be in CMAKE_PREFIX_PATH exported by ros_comm?

[nschoe]

@akru no I have added both diagnostic_msgs and ros_comm in my buildInputs.
The diagnostic_msgs being in the CMAKE_PREFIX_PATH comes from the fact that diagnostic_msgs is in buildInputs AFAIK.
But as soon as I source the setup.bash, diagnostic_msgs disappears from the CMAKE_PREFIX_PATH.

[nschoe]

Hum, okay so I have reverted to ros_comm version 1.13.6, and I observe the same thing...
I don't understand, then. What's the correct step?
Up to now, I would source ${ros_comm}/setup.bash and then source my own setup.bash inside my catking_workspace's devel/ directory.

But this doesn't work anymore: it complains it cannot find diagnostic_msgs's cmake file:

-- Could NOT find diagnostic_msgs (missing: diagnostic_msgs_DIR)
-- Could not find the required component 'diagnostic_msgs'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
CMake Error at /nix/store/a52dcjcjnfxlgv2xnnnlhcp5p3f9i9nf-catkin-0.7.14/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
  Could not find a package configuration file provided by "diagnostic_msgs"
  with any of the following names:

    diagnostic_msgsConfig.cmake
    diagnostic_msgs-config.cmake

  Add the installation prefix of "diagnostic_msgs" to CMAKE_PREFIX_PATH or
  set "diagnostic_msgs_DIR" to a directory containing one of the above files.
  If "diagnostic_msgs" provides a separate development package or SDK, be
  sure it has been installed.
Call Stack (most recent call first):
  kheops/CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!

This is weird because so far this has been working for months. Now suddenly it doesn't build anymore because of diagnostic_msgs.
Am I missing something obvious?

[akru]

For using ros_comm and diagnosic_msgs both try to use generated setup.bash of your package (parent of both packages). Unfortunatelly multiple source of setup.sh isn't support now. For this reason, I, for example, use meta-package to collect multiple packages in one derivation and do source from that. Example: https://github.com/airalab/robonomics_dev https://github.com/airalab/airapkgs/blob/nixos-unstable/pkgs/applications/science/robotics/aira/robonomics_dev/default.nix

[nschoe]

Thanks for your answer @akru.
So from what you're telling, I should not source several files, only my devel/setup.bash. I'll do that from now one, then.

Unfortunately, I did not understand how manage to build the projects in your catkin workspace. Do you ever use catkin_make yourself or do you only build through nix-build?
And how do you launch your programs? Do you run rosrun yourprogram? Or do you build entirely with nix and then launch the executable that it provides?

For now, these last 3-4 months, I have been making a shell.nix with every package I need inside buildInputs (currently this is buildInputs = [ libGL qtcreator qt5.full cmake boost167 eigen3_3 libuuid cryptopp ros_comm joy nav_msgs tf diagnostic_msgs pcl_msgs pcl_ros ];), then I would enter the shell with nix-shell, and I would build / dev on my project, by cd-ing into my catkin workspace and manually run catkin_make.

But maybe this the wrong way to go.
I do admit that over the past few months I had had inconsistent behaviors between:

• source-ing ${ros_comm}/setup.bash alone
• source-ing ${ros_comm}/setup.bash and my own devel.setup.bash
• source-ing my own devel/setup.bash only*

All three of them have worked at some point. But now I think I realize this was due to some dependencies that I was adding which would maybe cross or something.

So... what's the "correct" way to develop in your opinion?

Thanks again for your hard work. I'm taking notes on all of this and when it's sorted I'll definitely write something about it: there must be others trying to develop with ROS packages under nixOS!

[akru]

Thank you for your interest, ROS development under NixOS can be really hard for someone who don't known too much about nixpkgs internals. Writing an articles is a very very good point in my opinion.

So. I'm not sure that only one "correct" way really exist. In my opinion Nix provide a sea of opportunities. I try to describe my approach here. It's experience of year of using NixOS for ROS development.

The first, let we have a two sets of packages: the stable (should not be changed during development, like a ros_comm, pcl, etc.) and the development (your own development workspace and some external packages under development).

Packages from stable set should be installed during nix-env or nix-build with -o flag to provide permanent entry point to stable packages set (for nix-env way it's ~/.nix-profile/setup.bash, for nix-build ... -o stable it's stable/setup.bash). The stable set is very similar to /opt/ros/$distro from official ROS installation instructions. It's read-only and change this is undesirable.

Packages from development set can be placed anywhere in user home directory. It's regular catkin workspace and it can be created via command source $stable/setup.bash && mkdir -p ws/src && cd ws/src && catkin_init_workspace && cd .. && catkin_make. After that only source ws/devel/setup.bash is required to activate stable and development sets both. It's similar that official ROS docs describe too.

Trouble shooting

Of course described approach isn't ideal.

• The main problem of this approach is native dependencies of development package stack. Activation procedure can broke path to user installed deps and packages in workspace can't see it. The solution is using nix-shell after workspace activation to provide native dependencies for ROS packages in workspace. (your solution with nix-shell is too close to this point)

• Next problem is stable set formation. In case of one ros_comm as stable no more is needed and for building stable set only nix-build -A ros_comm -o ros_comm enough. But in mostly cases additional packages is required. For this reason I use meta-packages like robonomics_dev that incapsulate all stable dependencies of your project and have no code.

[nschoe]

Thanks @akru for this feedback, this is interesting.
I'm definitely writing an article about this when I feel like I understand things. This is too important IMO :)

I still have some questions regarding what you said:

Packages from stable set should be installed during nix-env or nix-build with -o flag to provide permanent entry point to stable packages set (for nix-env way it's ~/.nix-profile/setup.bash, for nix-build ... -o stable it's stable/setup.bash). The stable set is very similar to /opt/ros/$distro from official ROS installation instructions. It's read-only and change this is undesirable.

Let's consider the nix-build -o option (as I dislike having things installed with nix-env). Supposed I need two stable packages: ros_comm and pcl_ros. Then I build them with nix-build -A ros_comm -o ros_comm and nix-build -A pcl_ros -o pcl_ros. So I now have two local symlinks ros_comm and pcl_ros in the working directory.
Then you said to source stable/setup.bash, but in this case, what is stable: is it ros_comm or pcl_ros? Should I source ./ros_comm/setup.bash or source ./pcl_ros/setup.bash?

Then you said :

Packages from development set can be placed anywhere in user home directory. It's regular catkin workspace and it can be created via command source $stable/setup.bash && mkdir -p ws/src && cd ws/src && catkin_init_workspace && cd .. && catkin_make. After that only source ws/devel/setup.bash is required to activate stable and development sets both. It's similar that official ROS docs describe too.

In order to do this, it means you have catkin installed (either via nix-env or in your configuration.nix) globally in the system, right? Not much a problem, just wanted to make sure.

From what I understand, then you said it is only necessary to source ws/devel/setup.bash, I wonder how this works, though: will this recursively include the necessary changes of the stable dependencies?

Third question: when you talk about "activation procedure", do you mean source ws/devel/setup.bash?
If yes, then I don't understand this sentence:

The solution is using nix-shell after workspace activation to provide native dependencies for ROS packages in workspace. (your solution with nix-shell is too close to this point)

When you say "after workspace activation", am I correct thinking that you meant first enter nix-shell, then activate workspace? Because if we make in the reversed order, I believe nix-shell would erase the env variables set by activation.

I'm not too familiar with how meta package can be used, I think I need to read more about this.