# Need a little help understanding the rosmake/rospack machine; having issues with ROS_PACKAGE_PATH over Ansible [closed]

I'm in the process of creating an automated provisioning/deployment scheme at our lab to manage a sort of cluster of ROS/Gazebo minions; in order to codify and make this setup testable, I've begun pushing all of our hackneyed bash scripts and manual flits in to a set of Ansible playbooks.

I'm having issues when it comes time to build some software (osrf-common, sandia-hand, gazebo, drcsim) from source; we're trying to stay on the bleeding edge of these repos so in turn we want to be able to automate the process of checking out and rebuilding this software in step with the tip of the repos.

The problem I'm running in to is during the "make" process; at this point I haven't made it past osrf-common. In following the DRC build instructions, which I've done a million times by hand and via bash scripts with no issue, the invocation to "make" fails because the ROS_PACKAGE_PATH doesn't seem to get looked up correctly.

Ansible runs over SSH, and I'm aware of all the sorts of environment variable whackiness that comes along with this. That said, I've insured that the ansible command uses an interactive shell and during the build step that invokes make I'm double-checking that I am exporting the ROS_PACKAGE_PATH variable to the shell session correctly; I've even echo'd the variable back after exporting it to make sure that it's available to the shell session and it seems to be valid. But when make invokes rosbuild, rospack just isn't seeing the environment.

This could very easily be an issue with Ansible itself, but without understanding the gears and cogs that make up rospack/rosbuild/rosmake it's hard to see why the child processes aren't getting access to the exported variables

Update

Some more information: I've encountered an oddity. I am using a multi-machine Vagrant setup for localized testing, and I've seen that when I execute the playbook on the Vagrant cluster, the make command actually succeeds; it's only when I deploy the playbook on real machines on our local network that the command fails. I've also produced some sample output of the failed build (percentages are out of order because I'm doing make -j12, but non-parallel builds still fail):

Scanning dependencies of target osrf_msgs
[ 12%] Creating directories for 'osrf_msgs'
[ 12%] No download step for 'osrf_msgs'
[ 12%] [ 12%] No patch step for 'osrf_msgs'
No update step for 'osrf_msgs'
[ 12%] Performing configure step for 'osrf_msgs'
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonInterp: /usr/bin/python (found ...
edit retag reopen merge delete