Closed KamalanathanN closed 3 years ago
Hi there,
I am able to reproduce this bug when building the RMF workspace with ROS 2 foxy also built from source. Will look into this.
Hi @KamalanathanN
I tried to reproduce on my side but couldn't, to recap, on Ubuntu 20.04:
rmf_fleet_adapter_python
, through colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release --packages-up-to rmf_fleet_adapter_python
I get a few warnings but the build is successful:
--- stderr: rmf_fleet_adapter_python
CMake Warning at /home/luca/demos_ws/install/pybind_ament/share/pybind11/cmake/pybind11Tools.cmake:17 (message):
Set PYBIND11_PYTHON_VERSION to search for a specific version, not
PYTHON_VERSION (which is an output). Assuming that is what you meant to do
and continuing anyway.
Call Stack (most recent call first):
/home/luca/demos_ws/install/pybind_ament/share/pybind11/cmake/pybind11Common.cmake:195 (include)
/home/luca/demos_ws/install/pybind_ament/share/pybind11/cmake/pybind11Config.cmake:249 (include)
CMakeLists.txt:34 (find_package)
/home/luca/demos_ws/src/rmf/rmf_ros2/rmf_fleet_adapter_python/src/adapter.cpp: In function ‘void pybind11_init_rmf_adapter(pybind11::module_&)’:
/home/luca/demos_ws/src/rmf/rmf_ros2/rmf_fleet_adapter_python/src/adapter.cpp:176:39: warning: ‘rmf_fleet_adapter::agv::FleetUpdateHandle& rmf_fleet_adapter::agv::FleetUpdateHandle::accept_delivery_requests(rmf_fleet_adapter::agv::FleetUpdateHandle::AcceptDeliveryRequest)’ is deprecated: Use accept_task_requests() instead [-Wdeprecated-declarations]
176 | &agv::FleetUpdateHandle::accept_delivery_requests,
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/luca/demos_ws/install/rmf_fleet_adapter/include/rmf_fleet_adapter/agv/Adapter.hpp:20,
from /home/luca/demos_ws/src/rmf/rmf_ros2/rmf_fleet_adapter_python/src/adapter.cpp:11:
/home/luca/demos_ws/install/rmf_fleet_adapter/include/rmf_fleet_adapter/agv/FleetUpdateHandle.hpp:157:22: note: declared here
157 | FleetUpdateHandle& accept_delivery_requests(AcceptDeliveryRequest check);
| ^~~~~~~~~~~~~~~~~~~~~~~~
---
Do you still have this issue? I wonder if pulling the latest sources could help?
@luca-della-vedova well.... To reproduce the bug try building the entire rmf_ws.
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release
you ignored the only package(rmf_fleet_adapter_python) that didnt build 😅using --packages-up-to rmf_fleet_adapter_python
The rest of rmf repos were build perfectly for me without any warnings by using following command :
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release --packages-ignore rmf_fleet_adapter_python
you ignored the only package(rmf_fleet_adapter_python) that didnt build :sweat_smile: using --packages-up-to rmf_fleet_adapter_python
Just to clarify on this, the --packages-up-to xyz
option does include building package xyz
, so using that argument would not prevent @luca-della-vedova from seeing an error related to building that package.
One odd detail that sticks out to me, @KamalanathanN : In your description of the bug, you say that ROS2 was installed from source, but you also say that you use $ source /opt/ros/foxy/setup.bash
before building your rmf_ws
.
Does that mean that you used something like colcon build --install-prefix /opt/ros/foxy
to build and install ROS2? If so, I would very much discourage that. /opt/ros/foxy
is meant to be the installation folder for debian packages that you get from your package manager. Installing locally built packages to that folder could cause strange dependency issues that would be hard to diagnose.
What happens if you build your ros2 workspace with the default install prefix, as recommended by the ROS2 build instructions and then source that ROS2 workspace before building rmf_ws
?
There is a discrepancy in the description of the bug where the user states they built their RMF workspace with foxy
from source but end up sourcing /opt/ros/foxy/setup.bash
before the build.
I should clarify how I reproduced the error: I didn't follow the "steps to reproduce the bug". Instead I set up a single workspace with foxy
packages and RMF
packages. I then built the workspace with colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
. I added the --symlink-install
by virtue of following the ROS2 build instructions. This leads to the above mentioned error with rmf_fleet_adapter_python
. However if I run colcon build
without the --symlink-install
there is no build error. If one sets up two workspaces 1) Foxy and 2) RMF, where the first workspace is built with --symlink-install
(following ROS2 building instructions) and the second is built after sourcing the first (and without --symlink-install
, ie, following RMF build instructions), the error will not be encountered.
@KamalanathanN I am not sure if you followed the same steps but could you clarify exactly how your workspace(s) are setup and the commands used to source/build?
EDIT: The exact error I encounter is different from the user so I guess I didn't manage to "reproduce" it after all 🤔 . My error:
CMake Error: The source directory "/home/yadu/ws_foxy/build/rmf_fleet_adapter_python" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Traceback (most recent call last):
File "setup.py", line 91, in <module>
setup(
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 144, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.8/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.8/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3/dist-packages/setuptools/command/develop.py", line 38, in run
self.install_for_development()
File "/usr/lib/python3/dist-packages/setuptools/command/develop.py", line 140, in install_for_development
self.run_command('build_ext')
File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "setup.py", line 51, in run
self.build_extension(ext)
File "setup.py", line 84, in build_extension
subprocess.check_call(['cmake', ext.sourcedir] + cmake_args,
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '/home/yadu/ws_foxy/build/rmf_fleet_adapter_python', '-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/home/yadu/ws_foxy/build/rmf_fleet_adapter_python/', '-DPYTHON_EXECUTABLE=/usr/bin/python3', '-DCMAKE_BUILD_TYPE=Release']' returned non-zero exit status 1.
One odd detail that sticks out to me, @KamalanathanN : In your description of the bug, you say that ROS2 was installed from source, but you also say that you use
$ source /opt/ros/foxy/setup.bash
before building yourrmf_ws
.Does that mean that you used something like
colcon build --install-prefix /opt/ros/foxy
to build and install ROS2? If so, I would very much discourage that./opt/ros/foxy
is meant to be the installation folder for debian packages that you get from your package manager. Installing locally built packages to that folder could cause strange dependency issues that would be hard to diagnose.What happens if you build your ros2 workspace with the default install prefix, as recommended by the ROS2 build instructions and then source that ROS2 workspace before building
rmf_ws
?
@mxgrey you're right i'm really sorry for the error in the description(i've edited it now) ... actually during my initial tests i used foxy installed from source... later i switched to Installing ROS 2 via Debian Packages which at the time of reporting the bug i completely forgot that i switched.😬🤦♂️
@Yadunund , sorry for the confusion i'll clarify,
CMake Error at /home/kamal/rmf_ws_v2/install/pybind_ament/share/pybind11/cmake/pybind11Tools.cmake:147 (add_library):
Target "rmf_adapter" links to target
"std_msgs::std_msgs__rosidl_generator_c" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
Call Stack (most recent call first):
CMakeLists.txt:36 (pybind11_add_module)
Failed <<< rmf_fleet_adapter_python [2.57s, exited with code 1]
Summary: 48 packages finished [13.7s] 1 package failed: rmf_fleet_adapter_python 1 package had stderr output: rmf_fleet_adapter_python
one more thing... im not sure if its related but when i ``` rosdep install --from-paths src --ignore-src --rosdistro foxy -yr```
ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies: rmf_demos_panel: Cannot locate rosdep definition for [python3-flask-cors] Continuing to install resolvable dependencies...
i have installed it manually ```python3-flask-cors is already the newest version (3.0.8-2).``` but it still shows error 🙎♂️
Hi @KamalanathanN
We are fixing the issue that @Yadunund found, can you check if this PR in rmf_ros2 helps?
It actually removed pybind_ament
that seems to be the source of your issues.
one more thing... im not sure if its related but when i
rosdep install --from-paths src --ignore-src --rosdistro foxy -yr
ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies: rmf_demos_panel: Cannot locate rosdep definition for [python3-flask-cors] Continuing to install resolvable dependencies... #All required rosdeps installed successfully
i have installed it manually
python3-flask-cors is already the newest version (3.0.8-2).
but it still shows error pouting_man
If you installed it manually it should be ok, the key for python3-flask-cors
was added recently to rosdistro
very recently. The error should disappear if you run rosdep update
and try the rosdep install
command again.
@KamalanathanN Could you let us know if you're still experiencing this issue with the latest changes? If we don't hear back, we'll be closing this issue for lack of reproducibility.
@mxgrey sorry for the delay. The issue is resolved with latest changes. Thanks to everyone involved and looking forward to explore more of RMF :)
Bug report
Required information:
Description of the bug:
The rmf_fleet_adapter_python package fails to compile. Followed the instructions from : https://github.com/open-rmf/rmf
Steps to reproduce the bug:
Screenshots: