ros2 launch packages path

edit

I'll add that it is a specific choice to not have something like the ROS_PACKAGE_PATH (which would find packages even if they have not been built yet by searching) and instead require all packages to be installed before our tools can find them (allowing us to avoid all expensive searching).

But then the question surely is: why does ROS_PACKAGE_PATH find non-build packages? I've only ever pointed my ROS_PACKAGE_PATH to my install directories (and I thought it was the way it was supposed to be done...)

Thanks @jacobperron. In ROS1, the traditional, non-ROS-specific, cd build && cmake .. && make && make install sequence works great and install a setup.sh in $CMAKE_INSTALL_PREFIX. I'd rather do the same with ROS2 instead of using 'magic' tools like colcon.

@severin Totally Agreed! Inventing a new name "colcon", "ament", or what ever machin or truc, just makes ROS2 harder to use, wasting many people's time. I wish that ROS3 would come with a more standard build-system that would be welcoming to new contributors.

@Zhoulai Fu if you know an existing build system which satisfies all the requirements of ROS (processing federally dev. pkgs in a single invocation, support for CMake/Python pkgs etc., working across all target platforms, supporting cross compilation) please feel free to suggest it.

@Dirk Thomas I do not know, but what were the challenges for using only a traditional CMake-based build system (that works well on the Clang project, for example) ?

ament_cmake is plain CMake plus helper functions you can either use or decide to implement yourself. There is nothing non-CMake in ament_cmake. You can absolutely write a package in vanilla CMake (if you prefer to do everything by hand). Also CMake does not address the question of Python packages where you want to use something native to Python development (which is setup.py / setuptools). And CMake doesn't scale well to building numerous CMake packages efficiently - therefore we use a build tool which invoked cmake for each package in the right order.

Now I see that "ament_cmake" is a CMake wrapper that helps overcome CMake efficiency issues and issues related to python setuptools. Thank you very much for your detailed explanation, @Dirk Thomas.